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: Mon, 28 Apr 2025 09:39:46 -0700
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <86frhs8ckt.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> <86a59clr3a.fsf@linuxsc.com> <87ldsw8zer.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 28 Apr 2025 18:39:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9b77e479cbdf9133d482bf0bb96e0041";
	logging-data="3912524"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19SMBZ5iA+qJmbOYRlbgW56CSf9b41KJaA="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:U7GXOQSj6O4zdHB31pm5xASrXDk=
	sha1:i/jeJ1YoOLve6UH6gzagY8GDw58=
Bytes: 3236

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> 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.
>
> I had already mentioned that distinction earlier in the thread.

Oh, I must have missed that.  I don't remember seeing it in
the message I was replying to.

>> The mistake is thinking that UB for uninitialized access was
>> removed in C99.  It wasn't.  Narrowed, yes;  removed, no.
>
> Acknowledged.

Good deal.