Fwd: Using _GLIBCPP_RESOLVE_LIB_DEFECTS in the testsuite?

[Doug Gregor]

I neglected to Cc the list:

Begin forwarded message:
> From: Doug Gregor <dgregor@apple.com>
> Date: Fri Jun 6, 2003  8:06:53 AM US/Pacific
> To: Benjamin Kosnik <bkoz@redhat.com>
> Subject: Re: Using _GLIBCPP_RESOLVE_LIB_DEFECTS in the testsuite?
>
>
> On Thursday, June 5, 2003, at 05:43 PM, Benjamin Kosnik wrote:
>
>>
>>> However, I'm implementing a
>>> debug mode and the distinction does matter (because the testcase 
>>> fails
>>> without the DR semantics).
>>
>> Hmm. Can you be more elaborate about what it is you are doing?
>
> Sure. I'm implementing a "debug mode" that performs additional 
> checking of the library usage, and will flag an error (by aborting, 
> throwing an exception, etc.) when the user invokes undefined behavior 
> in certain cases. The main component is iterator tracking: extra 
> information is associated with each iterator that describes, e.g., 
> what container it references, if it's singular, dereferenceable, or 
> past-the-end, etc. The library is annotated with assertions that use 
> this information for additional checks, e.g., that one does not try to 
> dereference a past-the-end iterator, or compare iterators that are not 
> in the same domain.
>
> A trivial example:
>   std::vector<int> v;
>   v.reserve(10);
>   v[0] = 5;
>   assert(v[0] == 5);
>
> The code looks (almost) correct and will run without errors, but 
> invokes undefined behavior. The debug mode will flag the error at the 
> access to v[0].
>
> Similar functionality exists in STLport (see 
> http://www.stlport.org/doc/debug_mode.html) and also in CodeWarrior's 
> standard library. The feature has been discussed before:
>   http://gcc.gnu.org/ml/libstdc++/2002-04/msg00216.html
>
>>  Are you
>> planning on integrating this with the public FSF sources?
>
> Yes. Apple intends to contribute this back to the FSF sources as soon 
> as it is feasible.
>
>> For the record, _GLIBCPP_RESOLVE_LIB_DEFECTS can be assumed to be
>> permanently set to 1. It's there as a marker for the maintainers as to
>> what diverged from the standard. I don't think the library will 
>> actually
>> compile without it.
>>
>> -benjamin
>
> So should we still note when testcases deviate from the standard as is 
> done in the library?
>
> 	Doug
>