Subject: Re: [ub] type punning through congruent base class?
From: Richard Smith (richardsmith_at_[hidden])
Date: 2014-01-16 16:34:04
On 16 January 2014 14:13, Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
> On 01/16/2014 10:48 PM, Richard Smith wrote:
> > There's one other rule that I'd overlooked in my prior messages.
> > [intro.object]/1 presents this beautiful model: "An object is a
> > region of storage. [...] An object is created by a definition (3.1),
> > by a new-expression (5.3.4) or by the implementation (12.2) when
> > needed.[...] An object has a storage duration (3.7) which influences
> > its lifetime (3.8). An object has a type (3.9)."
> > Trouble is, this model gives a vast quantity of real-world C++ code
> > undefined behavior, including any C-like code that uses the 'malloc'
> > technique described in this thread.
> Why? Applying the term "object" to something doesn't mean it's
> actually usable (outside of its lifetime); see 3.8p5.
int *p = (int*)malloc(sizeof(int));
*p = 0;
... does not contain a definition of an 'int', not a new-expression, nor a
temporary. Therefore, by 1.8/1, it does not create an object of type 'int'.
Therefore the assignment (presumably) has undefined behavior.
> Put differently: 1.8p1 doesn't say anything about "lifetime", it
> just says "object", which is a fairly vacuous term by itself.
> (I concur with your earlier point that the C++ wording 3.8p1
> "storage with the proper alignment and size for type T is obtained"
> isn't good enough, and we might need something akin to the
> C model of effective type, or apply the term "dynamic type"
> expressly for the memory-scribbling case.)
> ub mailing list
SG12 list run by herb.sutter at gmail.com