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.

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.)

Jens