Date: Fri, 17 Jan 2014 16:37:58 +0000
I really don't understand that you mean by 'lifetime is a meaningless concept for POD'. The C standards has had several aliasing bugs related to lifetime. I also do not understand "lifetime is required to exist in a retroactive sense around every subobject access." I think we have a lot of confusion already.
From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf Of David Krauss
Sent: Friday, January 17, 2014 7:16 AM
To: WG21 UB study group
Subject: Re: [ub] type punning through congruent base class?
On Jan 17, 2014, at 9:53 PM, Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
As for an object type with "trivial initialization", I suspect that the general confusion comes from the fact for some reasons the standards text assumed that it could just "optimize" that case without much confusion. But evidence appear to suggest otherwise. Complexity has grown, with increased likelihood of inconsistency. What is the meaning of T{ } when T is a POD struct? Do you think there is no lifetime there?
My impression (for what it's worth) is that a lifetime is required to exist in a retroactive sense around every subobject access. But the lifetime of a POD object does nothing but grant the possibility of accessing a subobject, which in turn has no special properties or invariants by virtue of the complete object.
So it's not to say there's no lifetime there, but POD lifetime is a meaningless concept because you can always just pull one out of thin air. (T{} is value-initialized, and assigning those zeroes does imply subobject accesses to be sure.)
What evidence otherwise? It sounds like Richard is trying to push the envelope, but one would have to review existing verification/test tools to see if anyone has really tried to do anything with POD lifetimes. In a very real sense, POD objects are handed to any C++ program by the OS libraries in a fashion opaque to (outside the scope of) most verification tools. Programs need original input data to come out of thin air, and POD provides a way to structure such data while preserving its bytestream-like purity.
From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf Of David Krauss
Sent: Friday, January 17, 2014 7:16 AM
To: WG21 UB study group
Subject: Re: [ub] type punning through congruent base class?
On Jan 17, 2014, at 9:53 PM, Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
As for an object type with "trivial initialization", I suspect that the general confusion comes from the fact for some reasons the standards text assumed that it could just "optimize" that case without much confusion. But evidence appear to suggest otherwise. Complexity has grown, with increased likelihood of inconsistency. What is the meaning of T{ } when T is a POD struct? Do you think there is no lifetime there?
My impression (for what it's worth) is that a lifetime is required to exist in a retroactive sense around every subobject access. But the lifetime of a POD object does nothing but grant the possibility of accessing a subobject, which in turn has no special properties or invariants by virtue of the complete object.
So it's not to say there's no lifetime there, but POD lifetime is a meaningless concept because you can always just pull one out of thin air. (T{} is value-initialized, and assigning those zeroes does imply subobject accesses to be sure.)
What evidence otherwise? It sounds like Richard is trying to push the envelope, but one would have to review existing verification/test tools to see if anyone has really tried to do anything with POD lifetimes. In a very real sense, POD objects are handed to any C++ program by the OS libraries in a fashion opaque to (outside the scope of) most verification tools. Programs need original input data to come out of thin air, and POD provides a way to structure such data while preserving its bytestream-like purity.
Received on 2014-01-17 17:38:03