> 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
