Re: 1st draft: PRs fixed in 3.1.1

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <200207161752.KAA00555@atrus.synopsys.com> you write:

> Of your list, 6641 isn't really "fixed", it's just documented that
> the user must rebuild libstdc++ with __USE_MALLOC defined if s/he
> wishes to use it.

>> PR libstdc++/6641 -D__USE_MALLOC doesn't link

Hi Joe,

I think we did something beyond merely changing the documentation as
you state:

        libstdc++/6641
        * include/bits/c++config (__USE_MALLOC): Report case where
        the user improperly defined it on the command line.

; cat >t.C
#include <string>
int main() { }

$ ~/tmp-ref4/install-ref4-old/bin/g++ -D__USE_MALLOC t.C
In file included from $(prefix)/include/c++/3.1.1/string:45, from t.C:1:
$(prefix)/include/c++/3.1.1/$(target-triple)/bits/c++config.h:74:2:
#error __USE_MALLOC should only be defined within
libstdc++-v3/include/bits/c++config before full recompilation of the library.

> Since this used to be unnecessary, the regression
> is still present for users who used the feature before (the most common
> use was for memory leak detection).

As you know, just because something used to "link" does not mean it
"worked".  All sorts of chaos could result when a user recompiled a
portion of the C++ application with __USE_MALLOC and a portion
without.  Of course, the problem was that the one-definition rule was
violated.  The problem is visible when one compilation unit allocates
memory with one implementation keyed off __USE_MALLOC and another
compilation unit deallocates memory with an incompatible
implementation keyed off __USE_MALLOC.  It is possible that there was
a time (perhaps with v2) when the definition of __USE_MALLOC affected
none of the code actually compiled within libstdc++ and thus it was
safe to recompile only the user application code and not the entire
library but I assure you that this hasn't been true since libstdc++-v3
as released circa GCC 3.0.

The fact that we started with an implementation of STL from SGI and
someone could find documentation that such a macro exists for that
implementation when used apart from libstdc++-v3 does not allow a user
to add it in an ad hoc fashion.  The macro is in the unpublished
library implementation name space.

BTW, there has been an open call for a patch that makes memory
allocation strategy selectable without recompiling the entire
library/application but none has arrived.  Adding a macro to some but
not all compilation units is not the answer.  Using macros to expose
implementation choices in C++ headers (such as __USE_MALLOC) is a far
different ball game than macros that key the implementation in a
one-shot C/C++ compilation unit (or self-consistent set of units).

The reported compile-time error just enforces a rule that was
unchecked before.

Regards,
Loren