Re: Does reading an uninitialized object have undefined behavior?

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups	comp.std.c
Subject	Re: Does reading an uninitialized object have undefined behavior?
Date	2023-07-21 20:54 +0100
Organization	A noiseless patient Spider
Message-ID	<87fs5hnipv.fsf@bsb.me.uk> (permalink)
References	<87zg3pq1ym.fsf@nosuchdomain.example.com> <87zg3pnuse.fsf@bsb.me.uk> <874jlxozzz.fsf@nosuchdomain.example.com>

Show all headers | View raw

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> N3096 is the last public draft of the upcoming C23 standard.
>>>
>>> N3096 J.2 says:
>>>
>>>     The behavior is undefined in the following circumstances:
>>>     [...]
>>>     (11) The value of an object with automatic storage duration is
>>>          used while the object has an indeterminate representation
>>>          (6.2.4, 6.7.10, 6.8).
>>>
>>> I'll use an `int` object in my example.
>>>
>>> Reading an object that holds a non-value representation has undefined
>>> behavior, but not all integer types have non-value representations
>>> -- and if an implementation has certain characteristics, we can
>>> reliably infer that int has no non-value representations (called
>>> "trap representations" in C99, C11, and C17).
>>>
>>> Consider this program:
>>> ```
>>> #include <limits.h>
>>> int main(void) {
>>>     int foo;
>>>     if (sizeof (int) == 4 &&
>>>         CHAR_BIT == 8 &&
>>>         INT_MAX == 2147483647 &&
>>>         INT_MIN == -INT_MAX-1)
>>>     {
>>>         int bar = foo;
>>>     }
>>> }
>>> ```
>>>
>>> If the condition is true (as it is for many real-world
>>> implementations), then int has no padding bits and no trap
>>> representations.  The object `foo` has an indeterminate representation
>>> when it's used to initialize `bar`.  Since it cannot have a non-value
>>> representation, it has an unspecified value.
>>>
>>> If J.2(11) is correct, then the use of the value results in undefined
>>> behavior.
>>>
>>> But Annex J is non-normative, and as far as I can tell there is no
>>> normative text in the standard that says the behavior is undefined.
>>
>> 6.3.2.1 p2:
>>
>>   "[...] If the lvalue designates an object of automatic storage
>>   duration that could have been declared with the register storage class
>>   (never had its address taken), and that object is uninitialized (not
>>   declared with an initializer and no assignment to it has been
>>   performed prior to use), the behavior is undefined."
>>
>> seems to cover it.  The restriction on not having it's address taken
>> seems odd.
>
> Good find.
>
> That sentence was added in C11 (it doesn't appear in C99 or in
> N1256, which consists of C99 plus the three Technical Corrigenda)
> in response to DR #338.  Since the wording in Annex J goes back to
> C99 in its current form, and to C90 in a slightly different form,
> that can't be what Annex J is referring to.  And the statement
> in Annex J is more general, so we can't quite use 6.3.2.1p2 as a
> retroactive justification.

Thanks for looking into the history.  I was going to do that when I had
some time.

There are three relevant clauses in Annex J, and I think we should keep
them all in mind.  Sadly, they are not numbered (until C23) so I've
given then 'UB' numbers taken from the similar wording in C23.

  — The value of an object with automatic storage duration is used while
    it is indeterminate (6.2.4, 6.7.9, 6.8).  [UB-11]

  — A trap representation is read by an lvalue expression that does not
    have character type (6.2.6.1).  [UB-12]

  — An lvalue designating an object of automatic storage duration that
    could have been declared with the register storage class is used in
    a context that requires the value of the designated object, but the
    object is uninitialized. (6.3.2.1).  [UB-20]

Clearly, UB-20 is explained by the quote I posted, but UB-11 (the one we
are talking about) is there as well and, as you say, can't be fully
explained by that normative quote.

> https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_338.htm
>
> Yes, that restriction does seem strange.  It was inspired by the
> IA64 (Itanium) architecture, which has an extra trap bit in each
> CPU register (NaT, "not a thing").  The "could have been declared
> with the register storage class" wording is there because the IA64
> NaT bit exists only in CPU registers, not in memory.

Thanks.  I wondered if might have been some hardware consideration...

> An object with automatic storage duration might be stored in an IA64
> CPU register.  If the object is not initialized, the register's
> NaT bit would be set.  Any attempt to read it would cause a trap.
> Writing it would clear the NaT bit.
>
> Which means that a hypothetical CPU with something like a NaT bit
> on each word of memory (iAPX 432? i960?) might cause a trap in
> circumstances not covered by that wording -- but it *is* covered
> by the wording in Annex J.

It's covered by UB-12 and that's backed up by normative text,
specifically paragraph 5 of the section cited in UB-12.

> (Normally, an object whose address is taken can still be stored in
> a CPU register for part of its lifetime.  The effect is to forbid
> certain optimizations on I64-like systems.)
>
> It's tempting to conclude that reading an uninitialized automatic
> object whose address is taken is *not* undefined behavior
> (https://en.wikipedia.org/wiki/Exception_that_proves_the_rule),
> but the standard doesn't say so.

But it doesn't say that it is UB either, does it?  That case is excluded
in 6.3.2.1 p2, but there's not else covering it but the non-normative
Annex J.

> C90's Annex G (renamed to Annex J in later editions) says:
>
>     The behavior in the following circumstances is undefined:
>     [...]
>     - The value of an uninitialized object that has automatic storage
>       duration is used before a value is assigned (6.5.7).
>
> 6.5.7 discusses initialization, but doesn't say that reading an
> uninitialized object has undefined behave, so the issue is an old one.

-- 
Ben.

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Does reading an uninitialized object have undefined behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 22:16 -0700
Re: Does reading an uninitialized object have undefined behavior? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 16:33 +0100
Re: Does reading an uninitialized object have undefined behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 11:56 -0700
Re: Does reading an uninitialized object have undefined behavior? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 20:54 +0100
Re: Does reading an uninitialized object have undefined behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 14:26 -0700
Re: Does reading an uninitialized object have undefined behavior? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-21 23:39 +0100
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-12 17:00 -0700
Re: Does reading an uninitialized object have undefined behavior? Martin Uecker <ma.uecker@gmail.com> - 2023-08-13 23:41 -0700
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-15 21:06 -0700
Re: Does reading an uninitialized object have undefined behavior? Martin Uecker <ma.uecker@gmail.com> - 2023-08-15 22:40 -0700
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-16 23:13 -0700
Re: Does reading an uninitialized object have undefined behavior? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-17 07:08 +0000
Re: Does reading an uninitialized object have undefined behavior? Martin Uecker <ma.uecker@gmail.com> - 2023-08-18 12:44 -0700
Re: Does reading an uninitialized object have undefined behavior? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-19 05:04 +0000
Re: Does reading an uninitialized object have undefined behavior? Martin Uecker <ma.uecker@gmail.com> - 2023-08-19 01:36 -0700
Re: Does reading an uninitialized object have undefined behavior? Richard Damon <Richard@Damon-Family.org> - 2023-08-19 09:18 -0400
Re: Does reading an uninitialized object have undefined behavior? Martin Uecker <ma.uecker@gmail.com> - 2023-08-19 11:12 -0700
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-18 20:20 -0700
Re: Does reading an uninitialized object have undefined behavior? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-19 05:23 +0000
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-18 22:56 -0700
Re: Does reading an uninitialized object have undefined behavior? Martin Uecker <ma.uecker@gmail.com> - 2023-08-18 12:52 -0700
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-26 19:25 -0700
Re: Does reading an uninitialized object have undefined behavior? Spiros Bousbouras <spibou@gmail.com> - 2023-08-27 08:31 +0000
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-29 04:35 -0700
Re: Does reading an uninitialized object have undefined behavior? Spiros Bousbouras <spibou@gmail.com> - 2023-08-30 19:53 +0000
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-30 17:40 -0700
Re: Does reading an uninitialized object have undefined behavior? Spiros Bousbouras <spibou@gmail.com> - 2023-08-31 18:18 +0000
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 05:39 -0700
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 17:03 -0700
Re: Does reading an uninitialized object have undefined behavior? Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2023-09-07 17:09 +0200
Re: Does reading an uninitialized object have undefined behavior? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:19 +0100
Re: Does reading an uninitialized object have undefined behavior? Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2023-09-08 23:12 +0200
Re: Does reading an uninitialized object have undefined behavior? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-08 22:31 +0100
Re: Does reading an uninitialized object have undefined behavior? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-22 06:40 +0000
Re: Does reading an uninitialized object have undefined behavior? Martin Uecker <ma.uecker@gmail.com> - 2023-07-22 06:03 -0700
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-25 21:53 -0700
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-16 11:11 -0700
Re: Does reading an uninitialized object have undefined behavior? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-21 17:42 +0000
Re: Does reading an uninitialized object have undefined behavior? Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2023-07-24 07:53 +0200
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-25 21:57 -0700
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-03 13:13 -0700
Re: Does reading an uninitialized object have undefined behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-03 15:20 -0700
Re: Does reading an uninitialized object have undefined behavior? Martin Uecker <ma.uecker@gmail.com> - 2023-08-05 01:15 -0700
Re: Does reading an uninitialized object have undefined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-16 09:19 -0700
Re: Does reading an uninitialized object have undefined behavior? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-16 19:51 +0000
Re: Does reading an uninitialized object have undefined behavior? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-16 20:03 +0000
Re: Does reading an uninitialized object have undefined behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-16 13:43 -0700
Re: Does reading an uninitialized object have undefined behavior? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-16 21:08 +0000

csiph-web