Bug#194242: acknowledged by developer (Re: Bug#194242: drivers/atm/ambassador.c:301:21: pasting "." and "start" does not give a valid preprocessing token)
Brian M. Carlson wrote:
The standard says this is undefined behaviour. The code never "worked",
but by pure accident produced the expected result.
The compiler is *permitted* to make demons fly out of my nose, but if it
did that, I'd file a bug on it asserting that it shouldn't do that
either. Saying that the code never worked is at best, pedantic, and at
worst, false. The code compiled with gcc 3.2 into an ELF relocatable and
fails to do so with gcc 3.3.
3.2 (and some versions before it) warned that you shouldn't
rely on this working. Now, with 3.3, it indeed stopped working.
This is neither a surprise nor a problem.
If a .c file doesn't turn into a .o file, and it did with 3.2 [0], that's
a regression, and therefore a bug. You can argue for all eternity
Not if it isn't a valid C source file.
Neither #warning nor #error are valid C syntax either. But I'm sure
#error _is_ valid C syntax.
you'll find them in a great deal of C source files. Is it your
contention that gcc should outright reject every file which does not
comply with the C standard?
No, but it sure can't be expected to accept every erroneous
construct and "do the right thing" with it, whatever that
may be.
> And if so, which version of the C standard is that?
The version that was specified on the command line, of course.
> If not, what criteria are we to use to determine whether to
reject files which have syntax errors?
Every syntax error is a hard error.
Are you trying to convince me that it is a case of sheer stupidity? I
don't think that's what's happening here.
You're trying hard to suggest it is, though.
Segher
Reply to: