Date: Sat, 20 Feb 2021 09:06:18 +0000
Am Samstag, den 20.02.2021, 09:30 +0100 schrieb Jens Gustedt via Liaison:
> Jens,
>
> on Fri, 19 Feb 2021 22:31:15 +0100 you (Jens Maurer via Liaison
> <liaison_at_lists.isocpp.org>) wrote:
>
> > So, for anything but "unsigned char", even looking at
> > an uninitialized value is undefined behavior in C++
> > (in C parlance, there might be a trap representation).
>
> It is a bit more complicated in C, because of this weird `register`
> rule and because of pointers:
The C rules are a bit weird, but overall make sense to me.
The C++ rules seem far more problematic: The forbid useful
behavior that C allows. For example, computing as hash for
a struct including padding bytes and comparing it later.
I similar issue might exist for atomic_compare_exchange.
(I do not know what they did there to fix this).
At the same time it does not allow simple detection of
reads of uninitialized automatic variables because you
to take all this weird rules for unsigned char into
account.
This does strike me as very unfortunate design
choice (which also made language more different from C).
> - an lvalue conversion of an uninitialized object that is never
> backed-up in storage (whatever that means) is undefined.
You mean the "register" thing? This is very clear as
it is semantically equivalent to "address not taken".
> - if the object has pointer type, lvalue conversion is also
> undefined.
What is special about pointers? Any uninitialized object
with a type with trap representations can be UB.
> And current practice seems to be that C implementors do a lot of weird
> things when an uninitialized value is read other than byte-by-byte.
>
> I think C would gain a lot of simplification and clarity, if we'd just
> say that any lvalue conversion of an uninitialized object is
> undefined, unless the read is through a character type.
The "register"-rule was specifically introduced so that
reading uninitiazed automatic objects of character type
is UB. Removing this rule again might make the language
simpler again but then also prevents the compiler from
rejecting such errors.
Best,
Martin
> Jens,
>
> on Fri, 19 Feb 2021 22:31:15 +0100 you (Jens Maurer via Liaison
> <liaison_at_lists.isocpp.org>) wrote:
>
> > So, for anything but "unsigned char", even looking at
> > an uninitialized value is undefined behavior in C++
> > (in C parlance, there might be a trap representation).
>
> It is a bit more complicated in C, because of this weird `register`
> rule and because of pointers:
The C rules are a bit weird, but overall make sense to me.
The C++ rules seem far more problematic: The forbid useful
behavior that C allows. For example, computing as hash for
a struct including padding bytes and comparing it later.
I similar issue might exist for atomic_compare_exchange.
(I do not know what they did there to fix this).
At the same time it does not allow simple detection of
reads of uninitialized automatic variables because you
to take all this weird rules for unsigned char into
account.
This does strike me as very unfortunate design
choice (which also made language more different from C).
> - an lvalue conversion of an uninitialized object that is never
> backed-up in storage (whatever that means) is undefined.
You mean the "register" thing? This is very clear as
it is semantically equivalent to "address not taken".
> - if the object has pointer type, lvalue conversion is also
> undefined.
What is special about pointers? Any uninitialized object
with a type with trap representations can be UB.
> And current practice seems to be that C implementors do a lot of weird
> things when an uninitialized value is read other than byte-by-byte.
>
> I think C would gain a lot of simplification and clarity, if we'd just
> say that any lvalue conversion of an uninitialized object is
> undefined, unless the read is through a character type.
The "register"-rule was specifically introduced so that
reading uninitiazed automatic objects of character type
is UB. Removing this rule again might make the language
simpler again but then also prevents the compiler from
rejecting such errors.
Best,
Martin
Received on 2021-02-20 03:06:29