Jim Wilson wrote:
x z wrote:
If we want to fix this, gcc must change. And this may
also require GNU libc changes and linux kernel changes, etc.
Maybe you can enlighten us a bit on why GNU libc and linux kernel need
changes so that we can realize better how complicated the issue is.
Because there are header files in /usr/include that test __GNUC__. In
order for these header files to do the right thing, the Intel compiler
(and other compilers) need to define __GNUC__.
Now suppose we add a new macro __GCC_COMPILER__ that is intended to be
unambiguous, and mean only that this is the GCC compiler. What happens
next? Within a few months, someone will post a patch to glibc and/or
the linux kernel that uses __GCC_COMPILER__, based on the misconception
that because it is new, that they are supposed to use it.
I fully agree with the argument, but I'll add a caveat.
The __GNUC__ macro serves two different purposes:
1. permitting the extremely useful GCC languages extensions which, for
sad and various reasons, did not enter any official C standard (in
particular, computed gotos, statement exprs, typeof....). We might add
the extended asm instruction here also. I guess it is the most common
use of __GNUC__.
2. selecting one way of expressing (in perfectly usual C code) instead
of another which fits well with the GCC compiler in particular. I've got
no concrete example, but I could imagine some code like
#ifdef __GNUC__
int twice(int x) { return x*2; }
#else
int twice(int x) { return x<<1; }
#endif
Of course, the above example is very stupid, but I hope you get my
point. I expect this kind of use to be very rare.
And I agree that the separation is a bit fuzzy. Some people could argue
that some __builtin fits in between the two points.
Maybe we should separate the two roles above, and most importantly
*document* them, We might perhaps:
leave the __GNUC__ macro for the first role (GCC language extensions),
and perhaps define a __GCC_COMPILER__ macro for the second role, by
documenting it appropriately, and prohibiting any way of defining it
[except by patching the source code of GCC].
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
