On Sun, 11 Feb 2018 at 19:29, Gabriel Dos Reis <gdr_at_[hidden]> wrote:

> Thank you for following through!
>
> And taking care of the ‘memcpy’ and ‘memmove’ thingies.
>
>
>
> When we say that the operations implicitly creates an object, are we also
> to require that the bits patterns there be valid object representation?
> That would impose a severe restriction…
>

I think we need to allow cases like this:

struct X { int a, b; };
X *p = (X*)malloc(sizeof(X));
p->a = 1;
p->b = 2;

... where there is not necessarily a valid object representation in the *p
memory after the call to malloc, but we need for there to already be an
object there for the p->a assignment to be valid.

I think we should say that the created object -- or at least its scalar
subobjects -- contain an indeterminate value (the kind that means you get
UB if you try to read it, http://eel.is/c++draft/dcl.init#12) if the
storage doesn't contain a valid object representation.

For example, given:

char c = 7;
bool b; // assuming sizeof(b) == 1
memcpy(&b, &c, 1);

'b' should have the same behavior as an uninitialized bool, because we
"initialized" it with an invalid bool representation:

bool x = b; // undefined behavior

Does that seem reasonable to you?

*From:* ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] *On Behalf
> Of *Richard Smith
> *Sent:* Friday, February 9, 2018 11:52 AM
> *To:* ub_at_[hidden]
> *Subject:* [ub] new revision of p0593
>
>
>
> Hi all,
>
>
>
> Please find attached a revised version of P0593 based on the excellent
> discussion and feedback at the Albuquerque meeting. Please let me know if
> you have any comments; I believe our plan was to discuss this again at
> Jacksonville, and all being well, to forward it to EWG at that meeting.
>
>
>
> Best regards,
>
> Richard
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>