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]

"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

[Jaspreet]

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.

[littleroy]

#include <stdio.h>
#define BALANCE 5000

int main()
{
int balnace = BALNACE;

return 0;
}

the code have not any problem

[Keith Thompson]

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

[Kenneth Brody]

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.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Dale]

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

[Mike Wahler]

"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

[Mike Wahler]

"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

[Keith Thompson]

"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 "\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 (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.

[Keith Thompson]

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.

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

[Ben Pfaff]

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

[Joe Wright]

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

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Anonymous 7843]

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 "\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]

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.

[Richard Tobin]

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

[Anonymous 7843]

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

[Walter Roberson]

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

[Richard Tobin]

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

[Frodo Baggins]

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 "\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 (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

[Old Wolf]

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?

[Keith Thompson]

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

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

[Dave Thompson]

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