Messages in this thread | | | Subject | Re: support of older compilers | From | Nix <> | Date | Fri, 05 Nov 2004 15:36:43 +0000 |
| |
On 4 Nov 2004, Clayton Weaver stated: > I found that none of the gcc 3.x versions could > correctly compile a construct like this > (independent of runtime glibc version): > > file1.h: > > /* header boilerplate to avoid multiple #includes of > the same file */ > > #define STR1 "string 1" > > file2.c: > > #include "file1.h" > > const char * str2 = "whatever"STR1"stuff this\n\ > string has in it"STR1" and so on ad infinitum\n\ > "STR1"yada yada"; > > /* this was actually about 40 lines, maybe more, > with maybe 10 instances of "../"STR1"..." */ > > All of the gcc-3.x versions would bail with > an error trying to compile that str2 definition > in file2.c.
And do I see any bug reports from you in GCC bugzilla? I do not (not under the name `Clayton Weaver', anyway).
Further, the code you provide works in all the GCC-3.x versions I've got here.
If you don't even *report* the bug, how can you expect it to get fixed?
> They didn't always fail on literal string > concatenation (IIRC some short ones compiled > ok), but they consistently failed to concatenate > literal strings correctly for some source > files that gcc-2.95.3 would compile correctly > every time.
The preprocessor was totally rewritten between GCC-2.95.x and GCC-3.x: a number of things that were valid in 2.95.x but invalid under ISO C were made to not work in 3.x (for example, the compiler warns about attempts to concatenate two things with ## that aren't preprocessing tokens, and eventually this was made a hard error, IIRC).
This is, of course, not a bug.
I can find no mention of string concatenation bugs against the new preprocessor relating to anything other than token pasting (and all of those bugs are people trying to token-paste things that aren't tokens, generally strings).
> (The glibc trees had distributor patches, so I filed > the bug report via their support
What? You found a compiler bug, so you reported it as a bug against glibc?
> In sum: for production code it doesn't matter > what all a new C compiler version can do that > the old one could not if it won't compile > quite ordinary standard C correctly.
... especially if the people who see the problems don't report them and don't provide reproducible testcases.
> It would be good to have bugs fixed in the new compilers,
It would be good if people would report bugs in the new compilers. :)
> because they > obviously have some advantages (I noticed that gcc-3.4.x seemed quite > a bit faster than 2.95.3 when compiling glibc,
It is quite a bit slower :(
-- `Preliminary analysis reveal there are few impact craters on Titan. This suggests Cassini has an active surface constantly being resurfaced.' --- BBC News Online introduces a new planetary body - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |