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, 15 Aug 2023 21:06:37 -0700 Organization: A noiseless patient Spider Lines: 51 Message-ID: <864jkz7hrm.fsf@linuxsc.com> References: <87zg3pq1ym.fsf@nosuchdomain.example.com> <87zg3pnuse.fsf@bsb.me.uk> <874jlxozzz.fsf@nosuchdomain.example.com> <87fs5hnipv.fsf@bsb.me.uk> <87a5vpnegz.fsf@nosuchdomain.example.com> <86a5uv95g7.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="e1408e2ca4eb08ed594cd7d645ae4b51"; logging-data="3350239"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19869tiY0FH7CcLz7m6zOvaaVA/fNTvghE=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:DA7Fpv7RkKr3M1TXJpKqKpBXjKg= sha1:phfoPAcLuDd5+VzSc+XecqtOc0w= Xref: csiph.com comp.std.c:6533 Martin Uecker writes: > On Sunday, August 13, 2023 at 2:00:45?AM UTC+2, Tim Rentsch wrote: > >> Keith Thompson writes: >> >>> I think the right way for C to permit NaT-like bits is, as Kaz >>> suggested, to define "indeterminate value" in terms of provenance, >>> not just the bits that make up its current representation. [...] >> >> This idea is fundamentally wrong. NaT bits are associated with >> particular areas of memory, which is to say objects. The point >> of provenance is that non-viability is associated with /values/, >> not with objects. Once an area of memory acquires an object >> representation, the NaT bit or NaT bits for that memory are set >> to zero, end of story. Note also that NaT bits are independent >> of what type is used to access an object - if the NaT bit is set >> then any access is illegal, no matter what type is used to do the >> access. By contrast, provenance is used in situations where >> non-viability is associated with values, not with objects. But >> values are always type dependent; a pointer object that holds >> a value that has been passed to free() is "indeterminate" when >> accessed as a pointer type, but perfectly okay to access as an >> unsigned char type. The two kinds of situations are essentially >> different, and the theoretical models used to characterize the >> rules in the two kinds of situations should therefore be >> correspondingly essentially different. > > One could still consider the idea that "indeterminate" is an > abstract property that yields UB during read even for types > that do not have trap representations. There is no wording > in the C standard to support this, but I would not call this > idea "fundamentally wrong". You are right that this is different > to provenance provenance which is about values. What it would > have in common with pointer provenance is that there is hidden > state in the abstract machine associated with memory that > is not part of the representation. With effective types there > is another example of this. My preceding comments were meant to be only about NaT bits (or NaT-like bits) and provenance. There is an inherent mismatch between the two, as I have tried to explain. It is only the idea that provenence would provide a good foundation for defining the semantics of "NaT everywhere" that I am saying is fundamentally wrong. I understand that you want to consider a broader topic, and that, in the realm of that broader topic, something like provenance could have a role to play. I think it is worth responding to that thesis, and am expecting to do so in a separate reply (or new thread?) although probably not right away.