Parse error before token - Исправление ошибок и поиск оптимальных решений проблем

So I have written down this program to read an input of unvariable length in C. The code is this:

#include<stdio.h>
#include<stdlib.h>

struct ch{  
   char c;
   struct ch *next;
} *first;

struct Member {
   char *name1,*name2;
   struct Member *Next;
} *FName;

int scan(void);
int main()
{
    first=NULL;
    FName=NULL;
    scan();
    return 0;
}

int scan(void)
{
    int M,i,count;
    struct ch *O;
    O=(struct ch *)malloc(sizeof(struct ch));
    O=first;
    scanf("%d",&M);

    for(i=0;i<M;i++)
    while(scanf("%c",&first->c))
    {
        O=first->next;
        if(first->c==' ')
            if(!count)
            {
                struct Member *oldfirst;
                oldfirst=(struct Member *)malloc(sizeof(struct Member));
            oldfirst=FName;
            FName->name1=(char *)malloc((count+1)*sizeof(char));
            for(i=0;i<count;i++)
            {
                *FName->(name1+i)=first->c;     /*Error*/
                first=first->next;
            }
            *FName->(name1+count)='';         /*Error*/
            FName->Next=oldfirst;
            first=NULL;
            count=0;
        }
    if(first->c=='n')
        if(!count)
        {
            FName->name2=(char *)malloc((count+1)*sizeof(char));
            for(i=0;i<count;i++)
            {
                *FName->(name2+i)=first->c;     /*Error*/
                first=first->next;
            }
            *FName->(name2+count)='';         /*Error*/
            first=NULL;
            count=0;
        }

    O=first;
    count++;
}

return 0;
}

This is a part of the problem where I first need to take 2*M strings with two strings on each line separated by a space.

On compiling with GCC , I get the error: «parse error before ‘(‘ token». This error appears in 4 lines and I have marked them out in the code above. What is the problem here?

GoldRoger

1,2537 silver badges10 bronze badges

asked Apr 11, 2014 at 15:38

The -> operator denotes accessing members of a pointer to a struct. E.g.

typedef struct {
    int a;
} foo;

foo myFoo;
foo *fooPtr = &myFoo;
myFoo->a = 1;

Instead of the line:

*FName->(name2+count)='';

You probably want one of the following:

*(FName->name2 + count) = '';
FName->name2[count] = '';

answered Apr 11, 2014 at 15:47

robbie_crobbie_c

2,3881 gold badge17 silver badges28 bronze badges

*FName->(name1+i)

That’s just illegal syntax. You probably want something like:

*(FName->name1 + i) = ...

Or as Harry points in a different answer, the more sane:

FName->name1[i] = ...

answered Apr 11, 2014 at 15:47

cnicutarcnicutar

176k25 gold badges358 silver badges389 bronze badges

What about this:

FName->name1[i]=first->c;

answered Apr 11, 2014 at 15:51

HarryHarry

1,34211 silver badges19 bronze badges

Источник

const EPGState* NewEPGState[] =
{
    &bootupState,
    &standbyState,
    &watchtvState,
    &guideState,
    &settingsState,
    &easState,
    &diagnosticsState
};

What is wrong in this code? I am getting an error parse error before ‘*’ token
Your answers will be appreciated.

asked Feb 28, 2014 at 11:53

Check which version of the compiler are you using , This code compiles well on
g++ version 4.1.2 20071124.
but fails when compiled with gcc

I assume you have defined class/struct EPGState correctly and all the variables used below are of same type i.e EPGState.

class EPGState
{
};
int main()
{ 
    EPGState bootupState,standbyState;
   const EPGState* NewEPGState[] =
   {
       &bootupState,
       &standbyState
   };
}

Are you getting «parse Error» at the compilation step or at run time.
This is not clear from the question.

I written some sample code to test.

#include<iostream>
int main()
{
    int a;
    int b;
    int *ac[]={&a,&b};
    return 0;
}

Above code fails on gcc and compiles on g++.
gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)

/tmp/cc6829sJ.o: In function __static_initialization_and_destruction_0(int, int)': test1.cpp:(.text+0x4f): undefined reference to std::ios_base::Init::Init()

answered Feb 28, 2014 at 13:05

SinghSingh

3611 silver badge8 bronze badges

You probaly have

struct EPGState
{
  ...


struct EPGState bootupState = 
{
  ...

somewhere.

Then is shall be

const struct EPGState * NewEPGState[] =
{
    &bootupState,
    ...

answered Feb 28, 2014 at 14:54

alkalk

69.3k10 gold badges100 silver badges250 bronze badges

Источник

#include <stdio.h>
#define BALANCE 5000

int main(){
int balance = BALANCE;

return 0;
}

when i compile it, an error occurs,what’s happen?
ass3ext.c:9: error: parse error before ‘=’ token

thanks!

Nov 15 ’05
#1

«nick» <i1********@yahoo.com> wrote in message
news:di***********@justice.itsc.cuhk.edu.hk…

#include <stdio.h>
#define BALANCE 5000

int main(){
int balance = BALANCE;

return 0;
}

when i compile it, an error occurs,what’s happen?
ass3ext.c:9: error: parse error before ‘=’ token

Post the real code giving the error.
What you’ve posted should compile just fine.

-Mike

Nov 15 ’05
#2

nick wrote:

#include <stdio.h>
#define BALANCE 5000

int main(){
int balance = BALANCE;

return 0;
}

when i compile it, an error occurs,what’s happen?
ass3ext.c:9: error: parse error before ‘=’ token

thanks!

This code compiles properly on gcc 3.4.2. Please verify once again and
let us know what is the exact error.

Nov 15 ’05
#3

#include <stdio.h>
#define BALANCE 5000

int main()
{
int balnace = BALNACE;

return 0;
}

the code have not any problem

Nov 15 ’05
#4

«littleroy» <li***********@gmail.com> writes:

#include <stdio.h>
#define BALANCE 5000

int main()
{
int balnace = BALNACE;

return 0;
}

the code have not any problem

What?

Please learn to post properly; instructions have been posted repeatedly.

You re-posted *nearly* the same code from the original post, except
that the original code compiles (as numerous people have already
said), and yours doesn’t (you introduced typos because you didn’t post
the same code you compiled).

—
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Nov 15 ’05
#5

nick wrote:

#include <stdio.h>
#define BALANCE 5000

int main(){
int balance = BALANCE;

return 0;
}

when i compile it, an error occurs,what’s happen?
ass3ext.c:9: error: parse error before ‘=’ token

The sample code you posted is only 8 lines long, and the «=» is on
line 5, which make the error on line 9 hard to diagnose.

Please post a complete example of code which gives the error.

Nov 15 ’05
#6

nick <i1********@yahoo.com> wrote in news:dikd0q$2aoq$1
@justice.itsc.cuhk.edu.hk:

#include <stdio.h>
#define BALANCE 5000

int main(){
int balance = BALANCE;

return 0;
}

when i compile it, an error occurs,what’s happen?
ass3ext.c:9: error: parse error before ‘=’ token

thanks!

Some compilers get all pissy over stray nonprinting characters, causing
them to spew errors with no obvious cause.

(Did you copy the file from a Windows machine to a Unix box, by any chance?
I once used a compiler that gagged on the ^M that Windows puts at the end
of every line.)

Nov 15 ’05
#7

«littleroy» <li***********@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com…

#include <stdio.h>
#define BALANCE 5000

int main()
{
int balnace = BALNACE;

return 0;
}

the code have not any problem

Nick’s code is fine, no problem.

Your code, however, does have a problem.

-Mike

Nov 15 ’05
#8

«Dale» <da***@gas.orange> wrote in message
news:Xn*************************@204.153.244.156.. .

nick <i1********@yahoo.com> wrote in news:dikd0q$2aoq$1
@justice.itsc.cuhk.edu.hk:

#include <stdio.h>
#define BALANCE 5000

int main(){
int balance = BALANCE;

return 0;
}

when i compile it, an error occurs,what’s happen?
ass3ext.c:9: error: parse error before ‘=’ token

thanks!

Some compilers get all pissy over stray nonprinting characters, causing
them to spew errors with no obvious cause.

(Did you copy the file from a Windows machine to a Unix box, by any
chance?
I once used a compiler that gagged on the ^M that Windows puts at the end
of every line.)

In Windows, ‘^M’ is the (console’s) glyph for the ASCII
character with value 13, the ‘newline’ character. If you
have a C compiler that can’t handle newline characters
in a source file, dump it, fast.

-Mike

Nov 15 ’05
#9

«Mike Wahler» <mk******@mkwahler.net> writes:

«Dale» <da***@gas.orange> wrote in message
news:Xn*************************@204.153.244.156.. .

nick <i1********@yahoo.com> wrote in news:dikd0q$2aoq$1
@justice.itsc.cuhk.edu.hk:
[…] (Did you copy the file from a Windows machine to a Unix box, by any
chance?
I once used a compiler that gagged on the ^M that Windows puts at the end
of every line.)

In Windows, ‘^M’ is the (console’s) glyph for the ASCII
character with value 13, the ‘newline’ character. If you
have a C compiler that can’t handle newline characters
in a source file, dump it, fast.

Not quite. (The following is partially off-topic, but it’s relevant
to the handling of text files and of C source files.)

In Windows text files, the end-of-line marker is a CR followed by an
LF (ASCII codes 10 and 13, respectively). If you read a Windows text
file in binary mode, you’ll see the «rn» characters. If you read it
in text mode, the end-of-line marker will be translated to a single
«n» character; C calls this a «newline» character, ASCII calls it
«LF» or line-feed.

Unix text files use a single LF character to mark the end of a line;
no translation is necessary when reading a file in either text or
binary mode.

(Note that a C compiler needn’t be implemented in C, and needn’t
necessarily follow the rules of C text files when reading source
files.)

If you copy a Windows text file to a Unix system without translating
the end-of-line markers, the result will be an invalid text file with
an extraneous ‘r’ character (also represented as «^M») at the end of
each line. Though a Unix compiler can legally ignore extraneous ‘r’
characters, I don’t believe it’s required to.

Nov 15 ’05
#10

Dale <da***@gas.orange> writes:

nick <i1********@yahoo.com> wrote in news:dikd0q$2aoq$1
@justice.itsc.cuhk.edu.hk:

#include <stdio.h>
#define BALANCE 5000

int main(){
int balance = BALANCE;

return 0;
}

when i compile it, an error occurs,what’s happen?
ass3ext.c:9: error: parse error before ‘=’ token

thanks!

Some compilers get all pissy over stray nonprinting characters, causing
them to spew errors with no obvious cause.

(Did you copy the file from a Windows machine to a Unix box, by any chance?
I once used a compiler that gagged on the ^M that Windows puts at the end
of every line.)

Since the compiler is flagging an error before the ‘=’ token, it’s
unlikely that it’s a problem with end-of-line markers.

But since the OP still hasn’t shown us the actual code that causes the
error (or his compiler is broken in an unlikely fashion, or he’s
invoking it with «-Dbalance==»), there’s not much further point in
guessing.

This happens a lot around here. Somebody asks a question, half a
dozen people ask for more information, and we never hear from the
original poster again.

Nov 15 ’05
#11

nick <i1********@yahoo.com> writes:

#include <stdio.h>
#define BALANCE 5000

int main(){
int balance = BALANCE;

return 0;
}

ass3ext.c:9: error: parse error before ‘=’ token

Did you accidentally put an `=’ in the macro definition? We see
that around here from time to time.
—
«Your correction is 100% correct and 0% helpful. Well done!»
—Richard Heathfield

Nov 15 ’05
#12

Keith Thompson wrote:

«Mike Wahler» <mk******@mkwahler.net> writes:

«Dale» <da***@gas.orange> wrote in message
news:Xn*************************@204.153.244.156 …

nick <i1********@yahoo.com> wrote in news:dikd0q$2aoq$1
@justice.itsc.cuhk.edu.hk:
[…]
(Did you copy the file from a Windows machine to a Unix box, by any
chance?
I once used a compiler that gagged on the ^M that Windows puts at the end
of every line.)

In Windows, ‘^M’ is the (console’s) glyph for the ASCII
character with value 13, the ‘newline’ character. If you
have a C compiler that can’t handle newline characters
in a source file, dump it, fast.

Not quite. (The following is partially off-topic, but it’s relevant
to the handling of text files and of C source files.)

In Windows text files, the end-of-line marker is a CR followed by an
LF (ASCII codes 10 and 13, respectively). If you read a Windows text
file in binary mode, you’ll see the «rn» characters. If you read it
in text mode, the end-of-line marker will be translated to a single
«n» character; C calls this a «newline» character, ASCII calls it
«LF» or line-feed.

Unix text files use a single LF character to mark the end of a line;
no translation is necessary when reading a file in either text or
binary mode.

(Note that a C compiler needn’t be implemented in C, and needn’t
necessarily follow the rules of C text files when reading source
files.)

If you copy a Windows text file to a Unix system without translating
the end-of-line markers, the result will be an invalid text file with
an extraneous ‘r’ character (also represented as «^M») at the end of
each line. Though a Unix compiler can legally ignore extraneous ‘r’
characters, I don’t believe it’s required to.

Just a nit. The CPM/DOS/Windows text file line ending is CR, LF or 0D,
0A or 13, 10. Also there is the EOF character ‘^Z’ or 1A or 26 to tell
us the previous character was the last one. This last because CPM’s
directory structure maintained file sizes in 128-byte records, not
bytes. No big deal for binary stuff but if you want to concatenate two
text files, you really need to know where the first one ends.

Our C implementations on DOS/Windows pretend they are running on Unix so
that ‘text’ mode files that might have been written by DOS will be
‘treated’ such that 0D character is ignored and 1A will be treated as
EOF. The C program sees lines ending with 0A (‘n’) only. We never see
the 0D or 1A characters.

Orthogonally, our C implementation when writing text lines will enhance
the «n» to «rn» to make DOS/Windows happy. At least one C
implementation (from Software Toolworks for CPM circa 1980} will append
the 1A character on closing the text file.

—
Joe Wright
«Everything should be made as simple as possible, but not simpler.»
— Albert Einstein —

Nov 15 ’05
#13

In article <rb********************@comcast.com>,
Joe Wright <jw*****@comcast.net> wrote:

Just a nit. The CPM/DOS/Windows text file line ending is CR, LF or 0D,
0A or 13, 10. Also there is the EOF character ‘^Z’ or 1A or 26 to tell
us the previous character was the last one. This last because CPM’s
directory structure maintained file sizes in 128-byte records, not
bytes. No big deal for binary stuff but if you want to concatenate two
text files, you really need to know where the first one ends.

Our C implementations on DOS/Windows pretend they are running on Unix so
that ‘text’ mode files that might have been written by DOS will be
‘treated’ such that 0D character is ignored and 1A will be treated as
EOF. The C program sees lines ending with 0A (‘n’) only. We never see
the 0D or 1A characters.

Orthogonally, our C implementation when writing text lines will enhance
the «n» to «rn» to make DOS/Windows happy. At least one C
implementation (from Software Toolworks for CPM circa 1980} will append
the 1A character on closing the text file.

For the portability-crazed, macintosh text files are just CR
between lines (0x0D, or 13).

Also, it’s possible to autodetect this to some degree. Read in
the first 1024 bytes or so (in binary mode) and scan for control
characters.

some CR’s but no LF’s -> Mac
some LF’s but no CR’s -> Unix
same number (+/- 1) of CR’s and LF’s -> DOS
lots of null chars, control chars, or high bit set chars -> binary data
no control chars at all, just plain chars -> one line w/o a EOL indicator
lots of trailing space every 80 chars -> uh oh

Last time I dealt with this issue, I read the file byte by byte
in binary mode and cut the lines at CR’s and LF’s, but only made
one cut if the LF was immediately after a CR. This had the, uh,
feature that a concatenation of files from different machines
with different linefeed conventions would still work.

Now I have left a nit for someone else to pick…

Nov 15 ’05
#14

Joe Wright wrote:

Just a nit. The CPM/DOS/Windows text file line ending is CR, LF or 0D,
0A or 13, 10.

Those of us programming on PDP-1,5,6,7,8,10,11,12,15,20 etc. machines
long before «CPM/DOS/Windows» know that a CRLF is 15,12.

Nov 15 ’05
#15

In article <GcW3f.2483$i%.2376@fed1read07>,
Anonymous 7843 <an******@example.com> wrote:

For the portability-crazed, macintosh text files are just CR
between lines (0x0D, or 13).

Used to be. Macs are now unix.

— Richard

Nov 15 ’05
#16

In article <di**********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:

In article <GcW3f.2483$i%.2376@fed1read07>,
Anonymous 7843 <an******@example.com> wrote:

For the portability-crazed, macintosh text files are just CR
between lines (0x0D, or 13).

Used to be. Macs are now unix.

Oh well, it’s not like Teach Text was my editor of choice.

Nov 15 ’05
#17

In article <GcW3f.2483$i%.2376@fed1read07>,
Anonymous 7843 <an******@example.com> wrote:

Also, it’s possible to autodetect this to some degree. Read in
the first 1024 bytes or so (in binary mode) and scan for control
characters.
lots of null chars, control chars, or high bit set chars -> binary data

Or UTF-8 — for text that would fall into the normal ASCII range,
the first of every pair of characters is NUL.
—
«No one has the right to destroy another person’s belief by
demanding empirical evidence.» — Ann Landers

Nov 15 ’05
#18

In article <di**********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:

lots of null chars, control chars, or high bit set chars -> binary data

Or UTF-8 — for text that would fall into the normal ASCII range,
the first of every pair of characters is NUL.

That would be UTF-16 (and «first» would only be true for big-endian
UTF-16). UTF-8 is a variable-length encoding and is quite reliably
detectable because of strong constraints on sequences of bytes above
127.

— Richard

Nov 15 ’05
#19

Keith Thompson wrote:

«Mike Wahler» <mk******@mkwahler.net> writes:

«Dale» <da***@gas.orange> wrote in message
news:Xn*************************@204.153.244.156.. .

nick <i1********@yahoo.com> wrote in news:dikd0q$2aoq$1
@justice.itsc.cuhk.edu.hk: […] (Did you copy the file from a Windows machine to a Unix box, by any
chance?
I once used a compiler that gagged on the ^M that Windows puts at the end
of every line.)

In Windows, ‘^M’ is the (console’s) glyph for the ASCII
character with value 13, the ‘newline’ character. If you
have a C compiler that can’t handle newline characters
in a source file, dump it, fast.

Not quite. (The following is partially off-topic, but it’s relevant
to the handling of text files and of C source files.)

In Windows text files, the end-of-line marker is a CR followed by an
LF (ASCII codes 10 and 13, respectively). If you read a Windows text
file in binary mode, you’ll see the «rn» characters. If you read it
in text mode, the end-of-line marker will be translated to a single
«n» character; C calls this a «newline» character, ASCII calls it
«LF» or line-feed.

Unix text files use a single LF character to mark the end of a line;
no translation is necessary when reading a file in either text or
binary mode.

(Note that a C compiler needn’t be implemented in C, and needn’t
necessarily follow the rules of C text files when reading source
files.)

If you copy a Windows text file to a Unix system without translating
the end-of-line markers, the result will be an invalid text file with
an extraneous ‘r’ character (also represented as «^M») at the end of
each line. Though a Unix compiler can legally ignore extraneous ‘r’
characters, I don’t believe it’s required to.

—
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Hi
Linux offers two utlities : unix2dos & dos2unix
Hope that’s of some use.
Regards,
Frodo Baggins

Nov 15 ’05
#20

Martin Ambuhl wrote:

Joe Wright wrote:

Just a nit. The CPM/DOS/Windows text file line ending is CR, LF
or 0D, 0A or 13, 10.

Those of us programming on PDP-1,5,6,7,8,10,11,12,15,20 etc. machines
long before «CPM/DOS/Windows» know that a CRLF is 15,12.

Are you speaking in octal? Or is that just a coincidence?

Nov 15 ’05
#21

«Old Wolf» <ol*****@inspire.net.nz> writes:

Martin Ambuhl wrote:

Joe Wright wrote:

Just a nit. The CPM/DOS/Windows text file line ending is CR, LF
or 0D, 0A or 13, 10.

Those of us programming on PDP-1,5,6,7,8,10,11,12,15,20 etc. machines
long before «CPM/DOS/Windows» know that a CRLF is 15,12.

Are you speaking in octal? Or is that just a coincidence?

Assembly language on the PDP-11 used octal extensively, mostly because
most of the instruction fields (specifying registers, addressing
modes, etc.) were 3 bits wide. I’m guessing the same was true on the
other machines in the PDP-* series.

(I’m using past tense because these machines are no longer in wide
use, though I suppose some of them are still operational.)

Nov 15 ’05
#22

On Mon, 17 Oct 2005 22:14:30 GMT, Keith Thompson <ks***@mib.org>
wrote:

«Old Wolf» <ol*****@inspire.net.nz> writes:

Martin Ambuhl wrote:

Joe Wright wrote:

Just a nit. The CPM/DOS/Windows text file line ending is CR, LF
or 0D, 0A or 13, 10.

Those of us programming on PDP-1,5,6,7,8,10,11,12,15,20 etc. machines
long before «CPM/DOS/Windows» know that a CRLF is 15,12.
Are you speaking in octal? Or is that just a coincidence?

Assembly language on the PDP-11 used octal extensively, mostly because
most of the instruction fields (specifying registers, addressing
modes, etc.) were 3 bits wide. I’m guessing the same was true on the
other machines in the PDP-* series.

More or less. AFAIK no DEC machines except PDP-11 and VAX have
(explicitly coded, mostly orthogonal) modes.

(5 and) 8, and I believe 12 and 15, have 3-bit opcode, and for I/O
6-bit address and 3-bit function(s), but 7-bit local address and no
numbered registers. It also conventionally puts 2 x 6-bit characters
(ASCII 040-137 or special + 040-136) in 12-bit word.

(6 and) 10 have 9-bit opcode, but 4-bit GPR, but extensively uses 2 x
18-bit halfword which breaks nicely in octal, and sometimes uses 6 x
6-bit characters, but also much 5 x 7-bit + 1. There is no PDP-20;
DECsystem-10 and DECsystem-20 are different packagings of PDP-10.

7 (and 9) have 18-bit word, and (usually?) stores characters in either
6-bit bytes or 9-bit halfwords. I don’t remember instruction formats.

PDP-1 I never actually saw.

Some DECphiles (or maniacs?) who treasured their feeling of isolation
from and arguably superiority over IBM S/360 felt horribly betrayed
when VAX went almost-fully-byte and hex. At least not bigendian.
(I’m using past tense because these machines are no longer in wide
use, though I suppose some of them are still operational.)

The folks on comp.sys.pdp10 are proud that there are still a handful
of (competitive) clones in real use — to the absolute purist these
aren’t _true_ PDP-10’s but to a program, and programmer, they are.
<ObC> The company even funded a gcc port about 2 years back. </>
In addition there seem to be several hobbyist restorations and at
least one museum. As well as several(!) simulators for everyone else.

comp.sys.pdp{11,8} have several active hobbyists and hints of more,
and every few months or so reports of machines or at least parts
becoming available because they are being retired from service,
generally in niche applications that apparently have been undisturbed
— according to reports in some cases not even cleaned — for years.

I don’t try to follow the VAX and Alpha groups but I expect there are
still noticeable numbers of them. But aren’t in the PP list.

— David.Thompson1 at worldnet.att.net

Nov 15 ’05
#23

This discussion thread is closed

Replies have been disabled for this discussion.

Источник

Code:

double timebegin,timeend;
struct timeval tp;
struct timezone tz;

RFC_RC WIN_DLL_EXPORT_FLAGS cll_z_za0007_send(RFC_HANDLE hRfc) {

  /* RFC variables */
  unsigned crow;  
  static RFC_RC RfcRc;
  char s[1024];

  int i, k = 0, loc = 0, col, x, quan;
  char key[41], plant[5], csmat[11], cemat[11], cquan[4];
  unsigned long nsmat = 0, nemat = 0, nquan = 0;

  struct lead
  {
      unsigned long sapno;
      int deltime;
  };
  struct lead leadrec[1000];
  struct lead *leadacc;
  char delsap = 'S';
  char charsapno[19], chardeltime[4];
  int lrec = 0;

  /* char p[4097]; */
  char p[10000];
  int nLine=0;

  /* param variables */
  MSGNO iMsgno;//import par~var
  MSGV1 iMsgv1;
  SYST_MSGTY eZconfirm;
  ITAB_H thItab = ITAB_NULL;
  char xException[256];  

   /* table row variables */
    ZA0007 *tItab;

  /* init tables ------------------------------*/
  if (thItab==ITAB_NULL) {
    thItab = ItCreate("ITAB",sizeof( ZA0007),0,0);
    if (thItab==ITAB_NULL) rfc_error("ItCreate ITAB"); }
   else {
      if (ItFree(thItab) != 0) rfc_error("ItFree ITAB"); }
  

  /* input export parameters --------------------*/
  TRC((rlog.trc, "exporting parameters..."));
  SETCHAR(eZconfirm,"");
  SETCHAR(eZconfirm,"N");
    
  /* input table rows */
  memcpy(iMsgno.Msgno,"000",3);    
  /*iMsgno.Msgno[3]='x0';it*/
        
  PRT((rlog.prt,  ">>ZSAART:%s ZZSYS:%s", eZsaart.Zsaart, eZzsys.Zzsys ));/* del eZsaart.Zsaart*/
  TRC((rlog.trc,    "ZSAART:%s ZZSYS:%s", eZsaart.Zsaart, eZzsys.Zzsys ));/* del eZsaart.Zsaart*/
  /* call RFC function */
  sprintf((char *)function_name, "z_za0007_send");
  while ( !strncmp(iMsgno.Msgno, "000", 3) ){

    /* del RfcRc = z_za0007_send1(hRfc */
    alarm(300);
    RfcRc = z_za0007_send(hRfc
            ,&eZconfirm
            ,&eZsaart
                        ,&eZzsys
                        ,&iMsgno
                        ,&iMsgv1
            ,thItab
                        ,xException) ;

    switch (RfcRc) {

        case RFC_OK :
          /* display importing parameters */
          TRC((rlog.trc, "importing..."));          
                    
          /*GETCHAR(iMsgno.Msgno,s);*/
          TRC((rlog.trc, "MSGNO:%s", iMsgno.Msgno));
                              
          /*GETCHAR(iMsgv1.Msgv1,s);it*/
          TRC((rlog.trc, "MSGV1:%s",iMsgv1.Msgv1));

          if(ItFill(thItab) == 0) {
        PRT((rlog.prt, "<<%s",s));
        /*TRC((rlog.trc, "<<%s",s));*/
      }else{
            gettimeofday(&tp,&tz);
            timebegin=tp.tv_sec+(double)tp.tv_usec/1000000;
          PRT((rlog.prt, "Total %d Record(s)",ItFill(thItab) ));
          TRC((rlog.trc, "Total %d Record(s)",ItFill(thItab) ));
      }
      /* display tables */

      nLine=0;

          for (crow = 1;crow <= ItFill(thItab); crow++) {
                PRT((rlog.prt, "<<crow: %d, ItFill(thItab):%d", crow, ItFill(thItab) ));
                tItab = ItGetLine(thItab,crow);
                if (tItab == NULL) rfc_error("ItGetLine ITAB");
            
            /*GETNUM(tItab->Zkommid,s);
        PRT((rlog.prt,  "<<Zkommid:%s",  s));
        sprintf(s,"%d of %d lines",crow,ItFill(thItab));*/

                if (!strcmp(eZsaart.Zsaart, "H013"))
        {
            strncpy(key, tItab->Zvkey, sizeof(tItab->Zvkey));
            key[sizeof(tItab->Zvkey)] = '';
            /* PRT((rlog.prt, "<<Key:%s", key)); */
                    
            col = 1;
            quan = 0;
            loc = 0;
                    for (i = 0; i < 41; i++)
            {
            if (key[i] == ';')
            {
                if (col == 1)
                {
                    x = 0;
                if (loc == i)
                {
                        plant[x] = '';
                }
                {
                        for (k = loc; k < i; k++)
                        {
                        plant[x] = key[k];
                        x++;
                                    }
                        plant[x] = '';
                                }
                    loc = i + 1;
                col++;
                            }
                else if (col == 2)
                {
                    x = 0;
                if (loc == i)
                {
                        nsmat = 0;
                }
                {
                        for (k = loc; k < i; k++)
                        {
                        csmat[x] = key[k];
                        x++;
                        }
                        csmat[x] = '';
                        nsmat = atol(csmat);
                                }
                    loc = i + 1;
                col++;
                }
                else if (col == 3)
                {
                    x = 0;
                if (loc == i)
                {
                        nemat = 0;
                }
                {
                        for (k = loc; k < i; k++)
                        {
                        cemat[x] = key[k];
                        x++;
                        }
                        cemat[x] = '';
                        nemat = atol(cemat);
                                }
                    loc = i + 1;
                col++;
                }
                else if (col == 4)
                {
                    x = 0;
                if (loc == i)
                {
                }
                {
                        for (k = loc; k < i; k++)
                        {
                        cquan[x] = key[k];
                        x++;
                        }
                        cquan[x] = '';
                        nquan = atol(cquan);
                                }
                    loc = i + 1;
                col++;
                break;
                }
                        }
                    }

                    if (plant[0] == '')
               PRT((rlog.prt, "<<Oview<<No plantinfkey available"))
                    if (nsmat == 0)
               PRT((rlog.prt, "<<Oview<<No firstmatkey available"))
                    if (nemat == 0)
               PRT((rlog.prt, "<<Oview<<No lastmatkey available"))
                    if (nquan == 0)
               PRT((rlog.prt, "<<Oview<<No quankey available"))
                PRT((rlog.prt, "<<plant: %s", plant));
                PRT((rlog.prt, "<<nsmat: %lu", nsmat));
                PRT((rlog.prt, "<<nemat: %lu", nemat));
                PRT((rlog.prt, "<<nquan: %lu", nquan));
            
            tItab->Zvardata[tItab->Zdataln] = '';
            sprintf(p, "%s;", tItab->Zvardata);
            PRT((rlog.prt,  "<<%s",  p));

            leadacc = leadrec;
            lrec = 0;
                    loc = 5;
            for (i = 5; i < tItab->Zdataln + 1; i++)
            {
            if (p[i] == ';')
            {
                if (delsap == 'S')
                {
                                x = 0;
                for (k = loc; k < i; k++)
                {
                    635:if isdigit(p[k])
                    {
                        charsapno[x] = p[k];
                                    }
                                    else
                    {
                    charsapno[0] = '0';
                    x = 0;
                    k = i;
                                    }
                    x++;
                }
                charsapno[x] = '';
                loc =  i + 1;
                                leadacc->sapno = atol(charsapno);
                delsap = 'D';
                }
                652: else
                {
                                x = 0;
                for (k = loc; k < i; k++)
                {
                    if (x < 3)
                                    {
                        chardeltime[x] = p[k];
                                    }
                    else
                    {
                    chardeltime[0] = '0';
                    x = 0;
                    k = i;
                                    }
                    x++;
                }
                chardeltime[x] = '';
                loc = i + 1;
                leadacc->deltime = atoi(chardeltime);
                leadacc++;
                lrec++;
                delsap = 'S';
                }
            }
            }
            leadacc = leadrec;
            for (k = 1; k <= lrec; k++)
            {
            if (k == 1 && leadacc->sapno != nsmat)
                PRT((rlog.prt, "<<Oview<<firstmatkey != firstmatset: %lu != %lu", nsmat, leadacc->sapno))
                        if (k == lrec && leadacc->sapno != nemat)
                PRT((rlog.prt, "<<Oview<<lastmatkey != lastmatset: %lu != %lu", nemat, leadacc->sapno))
                        if (lrec != nquan)
                PRT((rlog.prt, "<<Oview<<numkey != numset: %lu != %i", nquan, lrec))
                    write_ams2_lt(leadacc->sapno, plant, leadacc->deltime);
                PRT((rlog.prt, "<<sap_no[%u] = %lu  ---   leadtime[%u] = %d", k, leadacc->sapno, k, leadacc->deltime));
            leadacc++;
            }
        }
        692:else
        {
             tItab->Zvardata[tItab->Zdataln]='';
            sprintf(p, "%s%s;", PRE_R3LOV, tItab->Zvardata);
            write_ams2(p, strlen(p));
            PRT((rlog.prt,  "<<%s",  p));
                }

        700:nLine++;
                701:PRT((rlog.prt, "<<loop end crow: %d, nLine:%d", crow, nLine));
    }

        if(ItFill(thItab) != 0) {
          gettimeofday(&tp,&tz);
          706:timeend=tp.tv_sec+(double)tp.tv_usec/1000000;
          707:PRT((rlog.prt, "%d Record(s) processed in %ld [seconds]",nLine, timeend-timebegin));
          708:TRC((rlog.trc, "%d Record(s) processed in %lf [seconds]",nLine, timeend-timebegin ));
    }
    710:SETCHAR(eZconfirm,"Y");    /*"Y"*/
        711:TRC((rlog.trc, "ZCONFIRM:'%s' confirmation sent",eZconfirm));
        break;

        case RFC_EXCEPTION :
              /* exception raised */          
              fprintf(stderr, "%s raised.",xException);                    
        717:ERR((rlog.err, "%s raised.",xException));
        718:rfc_error("rfc exception.");          
        case RFC_SYS_EXCEPTION :
        rfc_error("system exception raised");
        case RFC_FAILURE :
        rfc_error("failure");
        default :
        rfc_error("other failure");
      }
  }

  /* delete tables */
  if (ItDelete(thItab) != 0)
    rfc_error("ItDelete ITAB");

  return RfcRc;
}
/*** rfc_error() ******/
void rfc_error(char *operation) {

  RFC_ERROR_INFO RfcErrorInfo;
  ERR((rlog.err, "RFC error."));

  ERR((rlog.err, "operation:%s.", operation));

  memset(&RfcErrorInfo,0,sizeof(RfcErrorInfo));
  RfcLastError(&RfcErrorInfo);
  ERR((rlog.err, "key:%s", RfcErrorInfo.key));

  ERR((rlog.err, "status:%s", RfcErrorInfo.status));

  ERR((rlog.err, "message:%s", RfcErrorInfo.message));

  ERR((rlog.err, "internal status:%s", RfcErrorInfo.intstat));

  RfcClose (RFC_HANDLE_NULL);

  if( clean_up() == 0)
      TRC((rlog.trc, "DISCONNECTED from ORACLE..."));

  TRC((rlog.trc,  "END UP with exception. see %s file", err));

  if (outfile!=NULL) fclose(outfile);
  if(rlog.prt!=NULL) fclose(rlog.prt);
  if(rlog.err!=NULL) fclose(rlog.err);
  if(rlog.trc!=NULL) fclose(rlog.trc);

  exit(1);
}

Thanks.

Источник

ошибка синтаксического анализа перед токеном ‘)’ в функции-оболочке

Я пытаюсь скомпилировать следующую функцию-оболочку для системного вызова для моего класса операционных систем, и я продолжаю получать следующую ошибку компиляции.

Просто чтобы уточнить, этот код взят из задания HW, где нам нужно было добавить некоторые функции в task_struct. Это Linux 2.4, работающий на виртуальной машине.

syscall_files.h: In function `get_all_events_number`:
syscall_files.h:58: parse error before ')' token


int get_all_events_number(){
    long __res;
    __asm__ volatile (
            "movl $245, %%eax;"
            "int $0x80;"
            "movl %%eax, %0"
            : "=m" (__res)
            : "%eax"
    ); << line 58
    if((unsigned long)(__res) >= (unsigned long)(-125)) {
        errno = -(__res);
        __res = -1;
    }
    return (int)(__res);
}

Кто-нибудь может увидеть проблему? Я пытался понять это последние 30 минут, и я понятия не имею, что не так.

Не тот ответ, который вы ищете? Просмотрите другие вопросы с метками

c++
c
syntax-error
inline-assembly

or задайте свой вопрос.

Источник

This discussion thread is closed

Читайте также: