Comment regarding __GNUC__ spoofing
In discussions with the Intel folks about their spoofing of __GNUC__ on Linux, Clark Nelson pointed out that Boost code should be much more careful about use of any predefined compiler identification macro, because there is nothing to prevent any compiler in the future predefining compiler identification macros used by other compilers. Scary as it is, he is right AFAICS. There are two cases I can see for checking a compiler identification macro: * The code wishes to see if it is safe to use an extension feature such as a pragma or compiler intrinsic provided by the compiler indicated by the macro. This is reasonably safe in that presumably the reason the actual compiler is pretending to be a different compiler is to indicate feature compatibility with the spoofed compiler. * The code wishes to apply a workaround for a bug in the spoofed compiler. This usage is fraught with possible problems. The actual compiler may or may not have the same bug. If not, useful functionality may be needlessly disabled or the workaround may not even work. We deal with _MSC_VER in various compilers by defining BOOST_MSVC if it is actually the Microsoft compiler. We deal with __GNUC__ inconsistently by defining BOOST_INTEL rather than BOOST_GCC. To be consistent and to prevent being blindsided in the future by other compilers deciding to spoof one another's macros, perhaps we should define BOOST_x, where x is the compiler name, for every compiler we have a config for. And then pointing out the problem in our lib guide for developers. --Beman
Le mar 02/03/2004 à 09:57, Pavel Vozenilek a écrit :
"Beman Dawes" <bdawes@acm.org> wrote
We deal with __GNUC__ inconsistently by defining BOOST_INTEL rather than BOOST_GCC.
BOOST_INTEL_LINUX and BOOST_INTEL_WIN32 please.
They are different animals and different set of bugs.
/Pavel
They are not totally different and have some bugs (or features) in common; it's the reason why BOOST_INTEL was added in the first place. There were places in Boost where there was this preprocessor test: #if defined(__ICL) || defined(__ICC) || defined(__ECC) || defined(__INTEL_COMPILER) Now it looks a bit saner thanks to BOOST_INTEL. If you want to add BOOST_INTEL_LINUX and BOOST_INTEL_WIN32 and BOOST_INTEL_??? (how do you call the macro for the HP/UX version of the compiler? and the other versions? Intel does a bit more than just supporting Linux and Windows), fine. But please don't remove BOOST_INTEL, it has its own utility. Regards, Guillaume
At 03:57 AM 3/2/2004, Pavel Vozenilek wrote:
"Beman Dawes" <bdawes@acm.org> wrote
We deal with __GNUC__ inconsistently by defining BOOST_INTEL rather
than
BOOST_GCC.
BOOST_INTEL_LINUX and BOOST_INTEL_WIN32 please.
They are different animals and different set of bugs.
Well, sorry, but the current version of <boost/config/compiler/intel.hpp> defines BOOST_INTEL. --Beman
Beman Dawes wrote:
In discussions with the Intel folks about their spoofing of __GNUC__ on Linux, Clark Nelson pointed out that Boost code should be much more careful about use of any predefined compiler identification macro, because there is nothing to prevent any compiler in the future predefining compiler identification macros used by other compilers. Scary as it is, he is right AFAICS.
[...]
To be consistent and to prevent being blindsided in the future by other compilers deciding to spoof one another's macros, perhaps we should define BOOST_x, where x is the compiler name, for every compiler we have a config for. And then pointing out the problem in our lib guide for developers.
Or perhaps we should do nothing unless our tests indicate a problem or we get a bug report. Life is too short.
"Peter Dimov" <pdimov@mmltd.net> writes:
Beman Dawes wrote:
In discussions with the Intel folks about their spoofing of __GNUC__ on Linux, Clark Nelson pointed out that Boost code should be much more careful about use of any predefined compiler identification macro, because there is nothing to prevent any compiler in the future predefining compiler identification macros used by other compilers. Scary as it is, he is right AFAICS.
[...]
To be consistent and to prevent being blindsided in the future by other compilers deciding to spoof one another's macros, perhaps we should define BOOST_x, where x is the compiler name, for every compiler we have a config for. And then pointing out the problem in our lib guide for developers.
Or perhaps we should do nothing unless our tests indicate a problem or we get a bug report. Life is too short.
I think I favor the former, because it will allow us to write the BOOST_WORKAROUND macro in such a way as to avoid warnings. Otherwise, trying to track down a problem on a particular compiler could be a nightmare for anyone who isn't aware of all the spoofs that are in place. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Mon, 01 Mar 2004 20:24:34 -0500, Beman Dawes <bdawes@acm.org> wrote:
To be consistent and to prevent being blindsided in the future by other compilers deciding to spoof one another's macros, perhaps we should define BOOST_x, where x is the compiler name, for every compiler we have a config for. And then pointing out the problem in our lib guide for developers.
It's incredible, however, how proposals are appreciated in proportion to the author's authoritativeness. No polemic intent but I've proposed this 18 months ago (for libraries) and nobody agreed (please, don't tell me that for libraries "it is a different thing" :)). PS: I'm not angry, really, just noticing. -- Genny.
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Mon, 01 Mar 2004 20:24:34 -0500, Beman Dawes <bdawes@acm.org> wrote:
To be consistent and to prevent being blindsided in the future by other compilers deciding to spoof one another's macros, perhaps we should define BOOST_x, where x is the compiler name, for every compiler we have a config for. And then pointing out the problem in our lib guide for developers.
It's incredible, however, how proposals are appreciated in proportion to the author's authoritativeness. No polemic intent but I've proposed this 18 months ago (for libraries) and nobody agreed (please, don't tell me that for libraries "it is a different thing" :)).
PS: I'm not angry, really, just noticing.
I didn't notice a great chorus of assent to Beman's suggestion, nor to mine when I proposed the same thing. AFAIK nothing has been done about it to date. I'm not sure what you're noticing. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (6)
-
Beman Dawes -
David Abrahams -
Gennaro Prota -
Guillaume Melquiond -
Pavel Vozenilek -
Peter Dimov