Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.std.c Subject: Re: Does reading an uninitialized object have undefined behavior? Date: Tue, 25 Jul 2023 21:53:06 -0700 Organization: A noiseless patient Spider Lines: 28 Message-ID: <864jlrs28d.fsf@linuxsc.com> References: <87zg3pq1ym.fsf@nosuchdomain.example.com> <87zg3pnuse.fsf@bsb.me.uk> <20230721233227.651@kylheku.com> <21265efa-1bfe-4049-950f-45b75f0b4f71n@googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="5ba297a04e2080c4db730e1e3158367c"; logging-data="1490722"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+3YzKaLHNhqMnLjQSJlAagf6POW7Mys+g=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:DfLRlm0CsTWaX2oESGvB84IaESk= sha1:gBWhM8pLs9ZN/cfkL1NUwXx/RNQ= Xref: csiph.com comp.std.c:6520 Martin Uecker writes: > On Saturday, July 22, 2023 at 8:40:42?AM UTC+2, Kaz Kylheku wrote: > >> On 2023-07-21, Ben Bacarisse wrote: >> >>> 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. >> >> [...] > > I personally like this rule (but I am speaking about me. there is > no full consensus about the exact interpretation of the standard > nor about what it should say). I will try to explain why. [...] It's a good rule. I agree with your comments. I guess it's possible the wording could be improved, but compared to other parts of the C standard the clarity of this passage is closer to the top than it is to the bottom.