Re: [PATCH] Fix libstdc++/6642

[Paolo Carlini <pcarlini at unitus dot it>]

Hi Phil,

Phil Edwards wrote:

>On Sun, May 26, 2002 at 09:32:35PM +0200, Paolo Carlini wrote:
>  
>
>>2- I didn't wrap operator- in #ifdef _GLIBCPP_RESOLVE_LIB_DEFECTS since, 
>>otherwise, all the other non-member comparison operators should be 
>>wrapped too and provided also in the member form #ifndef. More 
>>generally, I seem to remember some mailings from Gaby maintaining that 
>>in fact the <Ready> DR are in fact part of the standard for all 
>>practical purposes.
>>    
>>
>At one point I think the idea was to support both "a C++ library as
>specified by the Standard," and also, "a C++ library as specified by
>the Standard with the latest round of committee fixes and suggestions."
>Defining this macro, or not, would switch between them.
>
>However, if _GLIBCPP_RESOLVE_LIB_DEFECTS is not defined, we cannot actually
>compile the library.  Therefore there seems little point in continuing to
>guard changes.
>
Very interesting... I could not even imagine that!

>So, it seems that this name has changed from something that switches between
>"strict compliance" and "strict compliance with bugfixes," to something
>that we can search for when asking the question, "which committee changes
>have we already implemented?"  And that seems to be okay; nobody has ever
>complained about not being able to build libstdc++ after removing the
>#define from c++config.
>
>As an example, look in include/std/std_bitset.h.
>
>My suggestion would be to add _GLIBCPP_RESOLVE_LIB_DEFECTS in a comment
>along with the DR number in the code you add.  For major bonus points,
>update docs/html/ext/howto.html#5 before I get around to it.  :-)
>
Ok. Thanks for the clarification on the current status of 
_GLIBCPP_RESOLVE_LIB_DEFECTS.
I was quite confused about it...

Specifically, if and when the fix for 6642 will be formally reviewed 
positively for trunk (and possibly branch if ABI issues will not hold 
it) I will incorporate your suggestions.

>Thanks very much for working on this, Paolo.  The iterator/const_iterator 
>mess has always been a thorn in my side.
>
Thanks.
Indeed, before the <Ready>, those could be considered "only" QoI issues, 
but really *boring* ones...

Ciao, Paolo.