This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Parser Bug
- To: root at localhost dot localdomain
- Subject: Re: Parser Bug
- From: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Date: Tue, 6 Jun 2000 09:34:43 +0200
- CC: gcc-bugs at gcc dot gnu dot org
- References: <00060519342600.00710@localhost.localdomain>
> 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