This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Remove unordered containers iterators default initialization
- From: Christopher Jefferson <chris at bubblescope dot net>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: Jonathan Wakely <jwakely dot gcc at gmail dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Wed, 27 Nov 2013 11:26:37 +0000
- Subject: Re: Remove unordered containers iterators default initialization
- Authentication-results: sourceware.org; auth=none
- References: <5293BAF5 dot 7070709 at gmail dot com> <CAH6eHdSaJAh5cXMteD-anBFZiG22SETkrCKC-wys2jqvOmrUug at mail dot gmail dot com> <5295176F dot 7010907 at gmail dot com>
On 26 November 2013 21:49, François Dumont <frs.dumont@gmail.com> wrote:
> On 11/26/2013 12:07 AM, Jonathan Wakely wrote:
>>
>> I don't think that will help diagnose errors.
>>
>> Dereferencing a null pointer will usually cause an immediate failure,
>> dereferencing uninitialized pointers can have more subtle, harder to
>> identify problems.
>>
> Ok, I see, it is not a Standard conforming issue but we prefer to be
> user friendly to performance. I was hoping to make all library iterators
> trivially default constructible and allow some good optimizations (even if
> std::is_trivially_default_constructible is not yet implemented).
Saying "we prefer to be user friendly to performance" is a massive
oversimplification -- but we have to consider each case in isolation.
I am sure there will be code in existence that uses this default
construction, and the bugs which will be introduced by this patch will
be very difficult to track down (precisely because they involve
uninitialized pointers).
At the same time, we are considering removing from our debugging mode
the ability to detect exactly this kind of problem, as it is the only
way we currently know to implement N3644!
> Frankly, I think that detecting usage of uninitialized variables is a
> compiler job. Is it part of the compiler feature or on its TODOs list ?
clang does this, with -fsanitize=memory. I know some fsanitize work is
being done in gcc, I don't know if this is planned, or already
implemented. Once that is implemented, and works well, that would make
this patch much easier to accept (for me at least).
Chris