This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Undefined behavior in locale_facets.tcc
- From: Jerry Quinn <jlquinn at optonline dot net>
- To: Doug Gregor <dgregor at apple dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Wed, 02 Jul 2003 22:35:18 -0400
- Subject: Undefined behavior in locale_facets.tcc
- References: <71F075EE-ACD7-11D7-B313-00039354D67A@apple.com>
Doug Gregor writes:
> However, we've never seen failures because:
> 1) __beg is always an istreambuf_iterator (22.2.5/1, and others like
> it, say we're allowed to assume this).
> 2) the libstdc++ istreambuf_iterator dereference operation returns
> traits_type::to_char_type(traits_type::eof()) when the iterator is
> past-the-end. This is an (undocumented) extension; 24.5.3/2 says the
> result is undefined.
>
> The end result is that the code works for our istreambuf_iterators
> because of the extension, but won't necessary work for anything else.
> Is there a policy regarding reliance on libstdc++ extensions within
> libstdc++ code? This is especially important for me because under debug
> mode the standard-specified semantics are checked, so the use of the
> extension causes the debug mode to flag an error. How do we want to
> work around this problem? I/we could:
>
> 1) Rewrite the offending code to not use the extension.
> 2) Hide the past-the-end check for istreambuf_iterator behind
> _GLIBCPP_DEBUG_PEDANTIC (which flags errors at uses of extension
> semantics).
> 3) Turn off checking around these blocks of code.
4) Change the standard :-)
The correct solution is probably to allow the extension for the
iterators we instantiate (char and wchar_t), and fix the code
otherwise. Assuming the extension actually buys any speed.
How hard is it to build a testcase that will fail?
Jerry Quinn