C++ Logo


Advanced search

Re: [wg14/wg21 liaison] C trap representations and unspecified values versus C++ indeterminate values

From: Jens Maurer <Jens.Maurer_at_[hidden]>
Date: Sat, 10 Oct 2020 10:54:03 +0200
On 10/10/2020 09.52, Uecker, Martin wrote:
> Am Samstag, den 10.10.2020, 00:32 -0400 schrieb Hubert Tong via Liaison:
>> On Fri, Oct 9, 2020 at 7:14 PM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:

>>> 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.
> Yes.
> With provenance, there is the idea that same representation could have
> different meaning in different context. I am not sure whether this
> plays a role here.

The idea is applicable here, and that's exactly what C++ does:
reading an uninitialized value of non-character type is undefined
behavior, even if there is no bit pattern that would be able
to represent such a state, distinct from any bit pattern
representing a valid value.

Thus, we have extra information beyond the bit pattern attached
to a variable.

>>> So, C says that uninitialized automatic variables have indeterminate value.
>>> That's fine for some types, because the implementation can choose to use
>>> a trap representation as the particular value used for that case,
>>> which makes any access undefined behavior.
>>> However, this avenue can't be taken for e.g. int16_t, because there are
>>> no bits left for a trap representation to be a possibility.
> (if the address is not taken, reading it is UB).

So, C already attaches extra information beyond the bit pattern to
uninitialized variables. Good.

In my view "if the address is not taken" is a hindrance for today's

void f(void)
  int x, y;
  &x; // vacuous
  y = x; // reads x; ok in C, undefined behavior in C++

Taking the address is (abstractly) a read-only operation, thus when
discarding its value, it should have no effect, and can be removed
aggressively. Except it can't, because it affects later value analysis.

>> Yes, and we're at risk of getting a hodge podge mix of the C and C++ rules
>> in implementations.
> Yes, but keep in mind, that there are also many C compilers that
> do not support C++.

We're talking about strictly reducing the guarantees given to users,
so existing implementations are not affected. (They just happen
to provide a little less undefined behavior in some cases.)


Received on 2020-10-10 03:54:10