Re: [PATCH] Fix PR libstdc++/19510: Uninitialized variable in some iterators

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Fri, Jan 21, 2005 at 12:26:18PM +0000, Jonathan Wakely wrote:
> On Thu, Jan 20, 2005 at 07:11:28PM -0800, Mark Mitchell wrote:
> 
> > My understanding is that the initialization being added is not required 
> > by the standard for the library (as opposed to the part of the standard 
> > that talks about acessing uninitialized values), but is required on 
> > certain architectures where copying uninitialized values is not allowed. 
>
> The proposed resolution to library DR 408, which Martin pointed out, says:
> 
>   [ We don't want to require all singular iterators to be copyable,
>   because that is not the case for pointers. However, default
>   construction may be a special case. Issue: is it really default
>   construction we want to talk about, or is it something like value
>   initialization? We need to check with core to see whether default
>   constructed pointers are required to be copyable; if not, it would be
>   wrong to impose so strict a requirement for iterators. ]
> 
> which implies it's an open issue whether uninit'd pointers are
> copyable. 

I don't think there's any doubt about whether uninitialized pointers
are poison.  They are.  The library recognizes "singular" values for 
iterator types, that cannot be copied safely, and a default-constructed
iterator must be assumed to be singular.  A class-type iterator cannot, 
strictly speaking, be uninitialized: some constructor or other must 
have been run.  However, that constructor might not initialize all 
members.  An iterator with an uninitialized member is almost certain 
to be a singular value.

There's a lot to be said for automatically detecting undefined uses of 
singular values.  Zeroing them doesn't, by itself, really help much.

> I think this is also related:
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#240

No.  That raises an issue about unsigned char, and about assignment.
Of course you can assign to an uninitialized pointer.

> As I think Gaby pointed out, debugging is easier if singular pointers
> are set to zero, not some random bit pattern.

At the last meeting I attended, there was serious talk about adding a 
requirement that default construction be required to zero native types, 
identically as for static objects.  I don't know if it went anywhere.  
If that happened, then I think the language would not have any cases 
of values that can be copied, but with undefined results.  

If I recall correctly, somebody tried it and found it had (counter-
intuitively) almost vanishingly little effect on performance.  Probably 
that's because everything actually used in a program gets initialized 
to something, and in most programs almost everything is used.

So, before demanding that implicit initialization _not_ be performed
by default, maybe somebody should measure it and see if it really hurts.
Guaranteed initialization would offer me a lot more convenience than
garbage collection, and would be a very helpful demonstration for the
committee, which just might adopt it in earnest.  Certainly any time
you eliminate the possibility of undetectable undefined behavior, the 
language is strengthened.  

It's no favor to users to make it easier for them to accidentally write 
less-portable code, but I'm not sure that applies here: a zeroed-out 
pointer is _more_ likely to be noticed than one that accidentally points 
where it oughtn't.

Nathan Myers
ncm-nospam@cantrip.org