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