parse error before '=' token

Discussion in 'C Programming' started by nick, Oct 13, 2005.

  1. nick

    nick Guest

    #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!
     
    nick, Oct 13, 2005
    #1
    1. Advertising

  2. nick

    Mike Wahler Guest

    "nick" <> wrote in message
    news:dikd0q$2aoq$...
    > #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
     
    Mike Wahler, Oct 13, 2005
    #2
    1. Advertising

  3. nick

    Jaspreet Guest

    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.
     
    Jaspreet, Oct 13, 2005
    #3
  4. nick

    littleroy Guest

    #include <stdio.h>
    #define BALANCE 5000

    int main()
    {
    int balnace = BALNACE;

    return 0;
    }

    the code have not any problem
     
    littleroy, Oct 13, 2005
    #4
  5. "littleroy" <> 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) <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, Oct 13, 2005
    #5
  6. 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:>
     
    Kenneth Brody, Oct 13, 2005
    #6
  7. nick

    Dale Guest

    nick <> 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.)
     
    Dale, Oct 13, 2005
    #7
  8. nick

    Mike Wahler Guest

    "littleroy" <> wrote in message
    news:...
    > #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, Oct 13, 2005
    #8
  9. nick

    Mike Wahler Guest

    "Dale" <> wrote in message
    news:Xns96EE92672B74610384893247@204.153.244.156...
    > nick <> 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
     
    Mike Wahler, Oct 14, 2005
    #9
  10. "Mike Wahler" <> writes:
    > "Dale" <> wrote in message
    > news:Xns96EE92672B74610384893247@204.153.244.156...
    >> nick <> 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) <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, Oct 14, 2005
    #10
  11. Dale <> writes:
    > nick <> 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) <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, Oct 14, 2005
    #11
  12. nick

    Ben Pfaff Guest

    nick <> 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
     
    Ben Pfaff, Oct 14, 2005
    #12
  13. nick

    Joe Wright Guest

    Keith Thompson wrote:
    > "Mike Wahler" <> writes:
    >
    >>"Dale" <> wrote in message
    >>news:Xns96EE92672B74610384893247@204.153.244.156...
    >>
    >>>nick <> 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 ---
     
    Joe Wright, Oct 14, 2005
    #13
  14. In article <>,
    Joe Wright <> 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...
     
    Anonymous 7843, Oct 14, 2005
    #14
  15. 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.
     
    Martin Ambuhl, Oct 14, 2005
    #15
  16. In article <GcW3f.2483$i%.2376@fed1read07>,
    Anonymous 7843 <> wrote:
    >For the portability-crazed, macintosh text files are just CR
    >between lines (0x0D, or 13).


    Used to be. Macs are now unix.

    -- Richard
     
    Richard Tobin, Oct 14, 2005
    #16
  17. In article <dipbqr$pj5$>,
    Richard Tobin <> wrote:
    >
    > In article <GcW3f.2483$i%.2376@fed1read07>,
    > Anonymous 7843 <> 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. :)
     
    Anonymous 7843, Oct 15, 2005
    #17
  18. In article <GcW3f.2483$i%.2376@fed1read07>,
    Anonymous 7843 <> 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
     
    Walter Roberson, Oct 15, 2005
    #18
  19. In article <dipk9i$7nl$>,
    Walter Roberson <-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
     
    Richard Tobin, Oct 15, 2005
    #19
  20. Keith Thompson wrote:
    > "Mike Wahler" <> writes:
    > > "Dale" <> wrote in message
    > > news:Xns96EE92672B74610384893247@204.153.244.156...
    > >> nick <> 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) <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
     
    Frodo Baggins, Oct 17, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. nitin
    Replies:
    2
    Views:
    1,123
    David Cattarin
    Jul 7, 2003
  2. Cronus
    Replies:
    1
    Views:
    681
    Paul Mensonides
    Jul 15, 2004
  3. learning_C++

    error: parse error before `(' token

    learning_C++, Sep 21, 2004, in forum: C++
    Replies:
    4
    Views:
    9,987
    Sharad Kala
    Sep 21, 2004
  4. Manuel
    Replies:
    3
    Views:
    1,039
    Ben Pope
    Jan 12, 2006
  5. Replies:
    2
    Views:
    588
Loading...

Share This Page