This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Parser Bug


> Files included that show what I think is a gcc parser bug:

Thanks for your bug report. It's not a bug in the compiler, but in
your code.

> (Please let me know if there is some way from the command line to
> redirect the error messages to a file - it would save time in having
> to re-type. I tried '>/tmp/gcc.out' and '2>/tmp/gcc.out', neither
> worked)

Redirecting error messages is a feature of your shell, and not of gcc.
If the Bourne shell notation did not work, you may be using a csh-alike.
In this case, >& gcc.out could have worked.

> This has made absolutely no difference. The error messages are the
> same and there is no '!=' binary operator in the source file at all
> after this change. I don't see how it could result from the
> expansion of a preprocessor macro, but I could be mistaken.

Yes, the confusing part is the error message. If gcc sees an if
statement of the form

  if(x)

and x is not a logical expression itself (e.g. integer), it interprets
it as

  if(x!=0)

Now, in your case, inpfile is a FILE*, so *inpfile is a FILE. So what
gcc does is

  if(<FILE> != <integer>)

which fails: you cannot compare a structure in that way. This is
really a bug in your code:

  if(*inpfile)

is not meaningful C code. I can't even guess what you meant to write:
If you want to check whether a file was passed, you need to write

  if(infile)

Or, if you want to check whether you've reached the end-of-file, write

  if(feof(file))

Hope this helps,
Martin

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]