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

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_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>