Am Samstag, den 20.02.2021, 10:31 +0100 schrieb Jens Gustedt:
> Martin,
>
> on Sat, 20 Feb 2021 09:06:18 +0000 you ("Uecker, Martin"
> <Martin.Uecker_at_[hidden]en.de>) wrote:
>
> > > - an lvalue conversion of an uninitialized object that is never
> > > backed-up in storage (whatever that means) is undefined.
> >
> > You mean the "register" thing? This is very clear as
> > it is semantically equivalent to "address not taken".
>
> Unfortunately this is not really a syntactical thing, but may depend
> of the interpretation which loads from memory have to be performed,
> and count as "address being taken".

The way it is formulated ("could have been declared with the
register storage class") makes it unambigous.

> > > - if the object has pointer type, lvalue conversion is also
> > > undefined.
> >
> > What is special about pointers? Any uninitialized object
> > with a type with trap representations can be UB.
>
> The problem here that this is not classical trap
> representation. Whether or not a byte pattern represents a valid
> pointer is dependent on the execution state. So in general, on many
> architectures there is no such thing as a trap representation: any
> byte pattern could represent a valid address (or a null pointer) at
> some point in time.

Loading an invalid segment register for an invalid
pointer could trap on real (though ancient)
architectures
(e.g. 286). So this is an excellent example of a trap
representation. Of course, today
we have a more abstract
definition of trap representation as a compiler could
treat something as a
trap representation at compile time
which is not a trap representation at run-time.

The main question for me is whether such compile-time trap
representations exist for integer types even when the
representation is fully specified by the standard.
It should in my opinion but this may require wording
changes. But this does not affect pointers where it is
clear that trap representation exists.


> Still there is this rule that an uninitialized pointer object has an
> "indeterminate value" (respectively an "indeterminate state" if we
> take your proposed changes). So lvalue conversion for it is not
> defined, and this makes it a special case to consider.

Can you point me to this rule? I thought all uninitialized
objects are in indeterminate state.

Best,
Martin