Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: int a = a Date: Sat, 22 Mar 2025 15:37:48 -0700 Organization: None to speak of Lines: 41 Message-ID: <87ldsw8zer.fsf@nosuchdomain.example.com> References: <87sen8u5d5.fsf@nosuchdomain.example.com> <86zfhgni2a.fsf@linuxsc.com> <87cyect356.fsf@nosuchdomain.example.com> <87msdfscxj.fsf@nosuchdomain.example.com> <87pliaqjb9.fsf@nosuchdomain.example.com> <86a59clr3a.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sat, 22 Mar 2025 23:37:49 +0100 (CET) Injection-Info: dont-email.me; posting-host="560ef87f14dda6eab647556d5657da3c"; logging-data="859590"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/eYoISJO8WgAvJnxVhFaAE" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:zfJ6yCQiWcoEU8ByC3ORQ9RivyY= sha1:liPDUbsJAyhh1PksQBbr2qc8xXQ= Bytes: 3056 Tim Rentsch writes: > Keith Thompson writes: >> David Brown 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. [...] > The mistake is thinking that UB for uninitialized access was > removed in C99. It wasn't. Narrowed, yes; removed, no. Acknowledged. [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */