parse error before '=' token

[nick]

#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!

 

[Mike Wahler]

#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

 

[Jaspreet]

#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.

 

[littleroy]

#include <stdio.h>
#define BALANCE 5000

int main()
{
int balnace = BALNACE;

return 0;
}

the code have not any problem

 

[Keith Thompson]

#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).

 

[Kenneth Brody]

#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.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Dale]

#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.)

 

[Mike Wahler]

#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

 

[Mike Wahler]

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

 

[Keith Thompson]

@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 "\r\n" 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]

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.

 

[Ben Pfaff]

#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.

 

[Joe Wright]

@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 "\r\n" 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 "\r\n" 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.

 

[Anonymous 7843]

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 "\r\n" 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...

 

[Martin Ambuhl]

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.

 

[Richard Tobin]

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

Used to be. Macs are now unix.

-- Richard

 

[Anonymous 7843]

Used to be. Macs are now unix.

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

 

[Walter Roberson]

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.

 

[Richard Tobin]

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

[/QUOTE]

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

 

[Frodo Baggins]

@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 "\r\n" 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.

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