Date: Mon, 12 Oct 2020 09:11:59 +0200
Hello,
on Fri, 9 Oct 2020 18:04:09 -0400 you (Hubert Tong via Liaison
<liaison_at_[hidden]>) wrote:
> Older thread appears to end here:
> http://open-std.org/JTC1/SC22/WG14/17199, "(SC22WG14.17199)
> terminology: indeterminate value"
>
> UB from uninitialized values emanates from indeterminate values in
> C++ and trap representations in C.
> C further has unspecified values that become unspecified at a specific
> point in time but can be copied without mutation of the value. C++
> received a National Body comment for C++14 where such cases were
> removed: https://wg21.link/cwg1787.
>
> It is further an issue that the definition of trap representation
> does not admit trap representations for the exact-width integer types
> (int16_t, etc.) because the lack of padding bits, combined with two's
> complement representation, means that every possible object
> representation represents a value of the type.
>
> I think it would really help if the C committee could record a
> decision to move towards harmonizing with C++ on this.
I don't know the C++ model well enough, but I think generally the
whole concept of C and C++ to have all of this within some sort of
value-state of objects (call it indeterminate or whatever) is an epic
failure.
If we really need this, I would prefer that we just said that lvalue
conversion of an unitialized object is undefined. To harmonize with
the happens-before relation we could then even say that the object
itself (not its storage instance) only starts its lifetime with the
initialization.
For me, it seems that such a terminology would well fit within C++'s
constructor/destructor model.
On a second level, I also think that our whole model of default
initialization is not well adapted to modern compiler
capacities. Instead of an optin for initialization of automatic
objects, a much better model would be optout.
Jens
on Fri, 9 Oct 2020 18:04:09 -0400 you (Hubert Tong via Liaison
<liaison_at_[hidden]>) wrote:
> Older thread appears to end here:
> http://open-std.org/JTC1/SC22/WG14/17199, "(SC22WG14.17199)
> terminology: indeterminate value"
>
> UB from uninitialized values emanates from indeterminate values in
> C++ and trap representations in C.
> C further has unspecified values that become unspecified at a specific
> point in time but can be copied without mutation of the value. C++
> received a National Body comment for C++14 where such cases were
> removed: https://wg21.link/cwg1787.
>
> It is further an issue that the definition of trap representation
> does not admit trap representations for the exact-width integer types
> (int16_t, etc.) because the lack of padding bits, combined with two's
> complement representation, means that every possible object
> representation represents a value of the type.
>
> I think it would really help if the C committee could record a
> decision to move towards harmonizing with C++ on this.
I don't know the C++ model well enough, but I think generally the
whole concept of C and C++ to have all of this within some sort of
value-state of objects (call it indeterminate or whatever) is an epic
failure.
If we really need this, I would prefer that we just said that lvalue
conversion of an unitialized object is undefined. To harmonize with
the happens-before relation we could then even say that the object
itself (not its storage instance) only starts its lifetime with the
initialization.
For me, it seems that such a terminology would well fit within C++'s
constructor/destructor model.
On a second level, I also think that our whole model of default
initialization is not well adapted to modern compiler
capacities. Instead of an optin for initialization of automatic
objects, a much better model would be optout.
Jens
-- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Received on 2020-10-12 02:12:05