And put me down for ‘std::bless’ :-)

From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf Of Gabriel Dos Reis
Sent: Sunday, February 11, 2018 8:18 PM
To: WG21 UB study group SG12 <ub_at_[hidden]>
Subject: Re: [ub] new revision of p0593


This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>

Feedback<http://aka.ms/SafetyTipsFeedback>

Yes, that covers my concern. Thanks!

From: ub-bounces_at_[hidden]<mailto:ub-bounces_at_[hidden]> [mailto:ub-bounces_at_[hidden]] On Behalf Of Richard Smith
Sent: Sunday, February 11, 2018 7:45 PM
To: ub <ub_at_open-std.org<mailto:ub_at_[hidden]>>
Subject: Re: [ub] new revision of p0593

On Sun, 11 Feb 2018 at 19:29, Gabriel Dos Reis <gdr_at_[hidden]<mailto: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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fdcl.init%2312&data=04%7C01%7Cgdr%40microsoft.com%7Cf8cc6d98cc0a4b2475cd08d571cb0db7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636540039291587184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=%2FLE2yv5uy0cmxO0vc14V75JLZ%2F%2BA6TFvfwSjwjU40T8%3D&reserved=0>) 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]> [mailto: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]<mailto:ub_at_[hidden]rg>
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]rg<mailto:ub_at_[hidden]>
http://www.open-std.org/mailman/listinfo/ub<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Fub&data=04%7C01%7Cgdr%40microsoft.com%7Cf8cc6d98cc0a4b2475cd08d571cb0db7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636540039291597188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=StkXetBejJn4SLnVI%2F6kDNodDQmGCE1hdtoLP20ZqW0%3D&reserved=0>