On 16 January 2014 14:13, Jens Maurer <Jens.Maurer@gmx.net> 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.

Because:

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

Jens

_______________________________________________
ub mailing list
ub@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/ub