Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: int a = a
Date: Sat, 22 Mar 2025 13:59:05 -0700
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <86a59clr3a.fsf@linuxsc.com>
References: <vracit$178ka$1@dont-email.me> <vrc2d5$1jjrf$1@paganini.bofh.team> <vrc4eb$2p28t$1@dont-email.me> <vrc75b$2r4lt$1@dont-email.me> <vrccjb$b3m6$1@news.xmission.com> <vrcef2$33076$1@dont-email.me> <vrelvn$12ddq$1@dont-email.me> <87sen8u5d5.fsf@nosuchdomain.example.com> <86zfhgni2a.fsf@linuxsc.com> <87cyect356.fsf@nosuchdomain.example.com> <vrhbsf$3e7sn$4@dont-email.me> <87msdfscxj.fsf@nosuchdomain.example.com> <vrjcd5$18m5n$1@dont-email.me> <87pliaqjb9.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sat, 22 Mar 2025 21:59:15 +0100 (CET)
Injection-Info: dont-email.me; posting-host="8c00933fd2fdb83fc14e0f99a9437a0f";
	logging-data="810064"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/aB5m0Beh84dfI4p7Mupho/a9GOeh5HGU="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:MoRyOzdw6+RH/pvxAo8rX4VD1o0=
	sha1:rq55xluul4e4TLnCiNSF3HuyAVA=
Bytes: 4696

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

> David Brown <david.brown@hesbynett.no> writes:
>
>> [...]I believe it would be much simpler and clearer if attempting
>> to read an uninitialised and unassigned local variable were
>> undefined behaviour in every case.
>
> I probably agree (I haven't given it all that much thought), but
> the committee made a specific decision between C90 and C99 to say
> that reading an uninitialized automatic object is *not* undefined
> behavior.  I'm don't know why they did that (though, all else
> being equal, reducing the number of instances of undefined
> behavior is a good thing), but reversing that decision for this
> one issue is not something they decided to do.

Your description of what was done is wrong.  It is still the case in
C99 that trying to access an uninitialized object is undefined
behavior, at least potentially, except for accesses using a type
that either is a character type or has no trap representations (and
all types other than unsigned char may have trap representations,
depending on the implementation).  A statement like

    int a = a;

may still be given a warning as potential undefined behavior, even
in C99.

>> Alternatively, it could have said that the value is unspecified
>> in every case.  Then on the IA-64, the compiler would have to
>> ensure that registers do not have their NaT bit set even if they
>> are not initialised - this would not be a difficult task.
>> Enabling use of the NaT bit for detection of bugs could then be a
>> compiler option if implementations wanted to provide that
>> feature.
>
> The whole point of the NaT bit is to detect accesses to
> uninitialized values.  Requiring the compiler to arbitrarily clear
> that bit doesn't strike me as a good idea.
>
> I dislike the way that wording was added to the standard
> specifically to cater to one specific CPU (which happens to have
> been discontinued later).  I would have been happier with a more
> general solution.  I that making accessing the value of an
> uninitialized automatic object UB would have been much cleaner,
> and it would have allowed for sensible use of NaT by IA-64
> compilers.

I think you may be missing a key point.  In both C99 and C11,
accessing an uninitialized object using a character type is defined
(albeit unspecified) behavior.  But in C11, because of the changes
in 6.3.2.1, even character types are subject to undefined behavior
when uninitialized objects are accessed (provided of course that
they don't fall under an exception because their address was taken).
The C11 rule does more than allowing undefined behavior just for
non-character types;  it extends the possibility of undefined
behavior to character types as well.

> But without knowing *why* the committee removed that UB between
> C90 and C99, I'm hesitant to say it was a mistake.

The mistake is thinking that UB for uninitialized access was
removed in C99.  It wasn't.  Narrowed, yes;  removed, no.  And
later C11 simply widened it back a bit, recovering some of the
territory that had been taken away in C99.  The Itanium may
have been what prompted the change, but the change that was made
is one well worth making.