This is the mail archive of the
mailing list for the libstdc++ project.
Re: [PATCH] Fix PR libstdc++/19510: Uninitialized variable in some iterators
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
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:
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.