[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.

["carlo at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #38 from carlo at gcc dot gnu dot org  2005-11-29 16:05 -------
That never works because it always defines _REENTRANT.
You probably mean:

#ifdef _REENTRANT
#define GCC_BUGFIX 1
#endif
#include <iostream>
#undef _REENTRANT
#ifdef GCC_BUGFIX
#define _REENTRANT 1
#endif

The drawback of this "fix" is that it is hardly usable for
library writers like you and me. You can add this to every
.cpp file of an application, but it doesn't help to determine
if the _user_ (of your library) wants thread-safeness or not.

Such a user will add -pthread when compiling his application
but we cannot detect that anymore. We can also not demand that
users of our library add the above kludge at the top of every
.cpp file of their application (before any system headers
are included) or, equivalently, demand they include the header
of our library before any system header.

That being said, I obviously agree completely with Marc that
this is a bug: _REENTRANT should only be defined by the compiler
iff -pthread is passed to the compiler. I know that is not
a written standard, but it certainly is widely used and something
developers have come to rely on so much that it is pure arrogance
to break it. I'd say, ignorance-- but given the fact that I reported
this BEFORE it was released (after running into it in a cvs version),
and it was released anyway...

Nevertheless-- I've seen enough of the gcc development (that is, what
is related with C++) to know that 'we' cannot rely on (the) g++ (developers)
being interested in keeping backwards compatibility with ANYTHING
that isn't set in stone by some ISO committee (refering to some GNU
extensions here).

Therefore I suggest to everyone reading this: don't rely on common sense.
The define of _REENTRANT isn't some standard and therefore you cannot not
rely on it (when using g++). Even if it was fixed in 4.1, you can count on
it being broken again in 4.2.

The only reliable "solution" left is to demand that the users define
a macro on the command line. So, expect to see this kind of compilations
in the future:

g++ -pthread -DBOOST_THREAD_SAFE -DLIBCWD_THREAD_SAFE -DLIBXML2_THREAD_SAFE
-DLIBC_THREAD_SAFE -DLIBFOO_THREAD_SAFE -DLIBGTK_THREAD_SAFE [...]
application.cc

until some guru proposes that all libraries make use of one and the same
define:
GURU_THREAD_SAFE.

Unfortunately... two decades later, once that macro made it's way into
AX[3.4]UbuOS-6.8 and some bug needs it to be defined always... g++ will
think it's allowed to unconditionally define GURU_THREAD_SAFE too... because
it wasn't an official standard [...]

Yeah, history repeats itself. Watch and see.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953