Date: Mon, 19 Jun 2023 12:59:41 -0500
Given:
int main() {
union U { int i; char c; };
U u{.i=1};
char c1 = (char&)u;
char c2 = (char&)u.i;
char c3 = u.c;
return c1 + c2 + c3;
}
c1, c2, and c3 are obviously equivalent here. If there's wording to suggest
otherwise, that's a wording defect.
On Mon, Jun 19, 2023 at 12:44 PM Myria via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> And yet ironically:
>
> char *p = &u.c;
> char *q = reinterpret_cast<char*>(&u);
> assert(p == q); // succeeds
> u.b = true;
> +*p; // undefined behavior
> +*q; // OK
>
> …I think.
>
> On Sun, Jun 18, 2023 at 16:07 language.lawyer--- via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> > I'm a bit confused by the OptBool examples from P2641
>> > (https://wg21.link/p2641#introduction). The paper claims that both are
>> > free from undefined behavior.
>> >
>> > Reduced case #1:
>> >
>> > union {
>> > bool b = true;
>> > char c;
>> > } u;
>> > +u.c;
>> >
>> > This reads from an inactive union member of type 'char'. The paper says
>> > that this is OK because of [basic.lval]/11.3, but I don't see how it
>> > applies here: we're not accessing a 'bool' through a glvalue of type
>> > 'char', we're accessing a distinct 'char' object outside its lifetime,
>> > which is undefined per [basic.life]/7.1.
>> >
>> > Reduced case #2:
>> >
>> > char c;
>> > new(&c) bool(true);
>> > +c; // #1
>> > +(bool&)c; // #2
>> >
>> > Creating a 'bool' in the storage associated with a 'char' ends the
>> > lifetime of the latter ([basic.life]/1.5), meaning #1 once again tries
>> > to access an object outside its lifetime. #2 does the same except
>> > through a 'bool' glvalue, additionally running afoul of [basic.lval]/11.
>> >
>> > Is there a mistake in the paper, or am I misunderstanding something?
>>
>> Your analysis is correct, I've pointed at the same things in Core
>> reflector half a year ago, and got no reaction from the authors. Not sure
>> what does it mean. 🌚
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
int main() {
union U { int i; char c; };
U u{.i=1};
char c1 = (char&)u;
char c2 = (char&)u.i;
char c3 = u.c;
return c1 + c2 + c3;
}
c1, c2, and c3 are obviously equivalent here. If there's wording to suggest
otherwise, that's a wording defect.
On Mon, Jun 19, 2023 at 12:44 PM Myria via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> And yet ironically:
>
> char *p = &u.c;
> char *q = reinterpret_cast<char*>(&u);
> assert(p == q); // succeeds
> u.b = true;
> +*p; // undefined behavior
> +*q; // OK
>
> …I think.
>
> On Sun, Jun 18, 2023 at 16:07 language.lawyer--- via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> > I'm a bit confused by the OptBool examples from P2641
>> > (https://wg21.link/p2641#introduction). The paper claims that both are
>> > free from undefined behavior.
>> >
>> > Reduced case #1:
>> >
>> > union {
>> > bool b = true;
>> > char c;
>> > } u;
>> > +u.c;
>> >
>> > This reads from an inactive union member of type 'char'. The paper says
>> > that this is OK because of [basic.lval]/11.3, but I don't see how it
>> > applies here: we're not accessing a 'bool' through a glvalue of type
>> > 'char', we're accessing a distinct 'char' object outside its lifetime,
>> > which is undefined per [basic.life]/7.1.
>> >
>> > Reduced case #2:
>> >
>> > char c;
>> > new(&c) bool(true);
>> > +c; // #1
>> > +(bool&)c; // #2
>> >
>> > Creating a 'bool' in the storage associated with a 'char' ends the
>> > lifetime of the latter ([basic.life]/1.5), meaning #1 once again tries
>> > to access an object outside its lifetime. #2 does the same except
>> > through a 'bool' glvalue, additionally running afoul of [basic.lval]/11.
>> >
>> > Is there a mistake in the paper, or am I misunderstanding something?
>>
>> Your analysis is correct, I've pointed at the same things in Core
>> reflector half a year ago, and got no reaction from the authors. Not sure
>> what does it mean. 🌚
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
Received on 2023-06-19 17:59:56