Let me add a small bit of context here.

On 10/10/2020 00.04, Hubert Tong via Liaison 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.

So, you're saying that the issue CWG 1787 highlighted for C++ is
equally an issue in C, and should be addressed in a similar fashion.

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

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.
But it's really helpful for optimizers to assume that uninitialized
automatic variables can't be read.

> I think it would really help if the C committee could record a decision to move towards harmonizing with C++ on this.

Yes. In particular since optimizers are likely to be the same for C and C++, anyway.

Jens