Path: csiph.com!weretis.net!feeder8.news.weretis.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: Wed, 30 Aug 2023 17:40:52 -0700 Organization: A noiseless patient Spider Lines: 105 Message-ID: <86zg28t563.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> <864jkz7hrm.fsf@linuxsc.com> <867cpu5h8w.fsf@linuxsc.com> <868r9xz0ek.fsf@linuxsc.com> <5+eRe7cp3yQjL4=AX@bongo-ra.co> <86sf82ulmb.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="49a0c7fba7d7c0f06cea865d80b29294"; logging-data="3098900"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/95rjl+oVAGbjt81ES9CG7oIKOzQs06QE=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Ze1BXDV1P3+7t3aIatUSA5AEohQ= sha1:drZdhrhKPVQILRkqN7UwYVb4dAw= Xref: csiph.com comp.std.c:6561 Spiros Bousbouras writes: > On Tue, 29 Aug 2023 04:35:40 -0700 > Tim Rentsch wrote: > >> Spiros Bousbouras writes: >> >>> On Sat, 26 Aug 2023 19:25:55 -0700 >>> Tim Rentsch wrote: >>> >>>> Sometimes people use compiler options to turn off, for example, >>>> so-called "strict aliasing", and of course the C standard allows >>>> us to do that. But compilers aren't required to provide such an >>>> option, and if they do the option may not do exactly what we >>>> expect it to do, because there is no standard specification for >>>> it. The C standard should define officially sanctioned >>>> mechanisms -- as for example standard #pragma's -- to give >>>> standard-defined semantics to certain constructs of undefined >>>> behavior that resemble, eg, -fno-strict-aliasing. >>> >>> Surely the starting point for this should be the documentation of >>> the compilers to specify precisely what -fno-strict-aliasing does. >>> [...] >> >> Not at all. It's easy to write a specification that says what we >> want to do, along similar lines to what is said in the footnote >> about union member access in section 6.5.2.3 >> >> If the member used to access the contents of a union object >> is not the same as the member last used to store a value in >> the object, the appropriate part of the object representation >> of the value is reinterpreted as an object representation in >> the new type as described in 6.2.6 (a process sometimes called >> "type punning"). This might be a trap representation. > > Works for me but it would be good to know that this is how compiler > writers actually understand -fno-strict-aliasing . [...] No, it wouldn't. Implementations follow the C standard, not the other way around. Looking at what implementations do for the -fno-strict-aliasing flag is worse than a waste of time. >>> For example it has been pointed out on comp.lang.c that it's >>> impossible to write a malloc() implementation in conforming >>> C. This is certainly a weakness which should be addressed with >>> some appropriate #pragma . >> >> There isn't any reason to think malloc() should be writable in >> completely portable C. That's the point of putting malloc() in >> the system library in the first place. By the way, with type >> punning semantics mentioned above being the default, and with the >> alignment features added in C11, I think it is possible to write >> malloc() in portable C without needed any additional language >> changes. But even if it isn't that is no cause for concern; one >> of the principal reasons for having a system library is to >> provide functionality that the core language cannot express (or >> cannot express conveniently). > > One might want to experiment with different allocation algorithms > and it seems to me that this sort of thing is within the "remit" of > C. So ideally one should be able to write it in C [...] You're conflating writing something in C and writing something in completely portable C. It's already possible to do these things writing in C. >>> From my point of view , restrict is not a success because the >>> specification of restrict is the one part of the C1999 standard I >>> have given up trying to understand. I understand the underlying >>> idea but the specifics elude me. [...] >> >> I agree the formal definition of restrict is rather daunting. In >> practice though I think using restrict with confidence is not >> overly difficult. My working model for restrict is something >> like this: >> >> 1. Use restrict only in the declarations of function >> parameters. >> >> 2. For a declaration like const T *restrict foo , >> the compiler may assume that any objects that can be >> accessed through 'foo' will not be modified. > > Wouldn't that also be the case with just const T * foo ? No. >> 3. For a declaration like T *restrict bas , >> the compiler may assume that any changes to objects >> that can be accessed through 'bas' will be done >> using 'bas' or a pointer value derived from 'bas' >> (and in particular that no changes will happen >> other than through 'bas' or 'bas'-derived pointer >> values). >> >> Is this summary description helpful? > > It seems clear enough but , as I've said , I don't have any use > for restrict anyway and it's not worth it for me to expend the > additional mental effort to confirm that my code obeys the > additional restrictions of restrict. [...] If you don't want to use restrict that is quite okay. Part of why I call restrict a success is that it can be ignored, with only minimal effort, by any developer who doesn't want to use it.