> 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.
> The talk about whether __GNUC__ is defined by the preprocessor or the
> compiler proper is irrelevant. Either way, it is still ambiguous.
IMHO, it is irrelevant as far as whether __GNUC__ is ambiguous. However,
I think it is relevant as far as how it can be fixed, if at all. So, if you
have some insight as to whether __GNUC__ is defined by the preprocessor
or the compiler proper, please let us know. It does not hurt anyway.
> You are right that we may also have trouble with other related macros.
> I am not sure if there is a GNU Fortran language, if there is, then we
> may have the same problem with __GFORTRAN__.
There is a GNU Fortran compiler for sure. So, just as people consider
the syntax and semantics of a language accepted by the GNU C compiler
as sort of a C language specification (i.e. whatever accepted by GNU C
compiler 4.3.1 becomes GNU C Standard 4.3.1), there is a GNU Fortran
language. Whatever accepted by the GNU Fortran compiler becomes
the GNU Fortran language spec.
> We don't need things like __GNUG_MINOR__ as G++ is always distributed in
> lock step with the C compiler, so we only need one set of macros for gcc
> version numbers.
Then maybe __GNUFORTRAN_MINOR__ .
Anyway, assumed GNU Fortran and GNU C are not distributed in lock step, then
the __VERSION__ macro should be clarified as to whether it refers to the
C or Fortran version (or the version of CPP itself - well, I guess CPP is also
distributed with C in lock step so they share the same version).
_________________________________________________________________
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008
