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
optimizers:

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.)

Jens