Date: Fri, 9 Oct 2020 18:04:09 -0400
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.
Thanks,
Hubert Tong
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.
Thanks,
Hubert Tong
Received on 2020-10-09 17:04:28