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, 29 Aug 2023 04:35:40 -0700 Organization: A noiseless patient Spider Lines: 110 Message-ID: <86sf82ulmb.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="1084eb5dd0b1a11121af7ba127734067"; logging-data="2364061"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX187fQ51468Qzx0z10c1Wy3q+xvH9NwObYk=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:NBGpuO8ev+U/Llqr5D8wc5p42zE= sha1:pZQE77+/rUs++M4WqAvumoBKBeY= Xref: csiph.com comp.std.c:6559 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. That behavior should be the default, for all accesses. For cases where a developer wants to give permission to the compiler to optimize based on cross-type non-interference assumptions, there should be a #pragma to do something similar to what effective type rules do now. The effective type rules are in need of re-writing anyway, and making type punning be the default doesn't break any programs, because compilers are already free to ignore the implications of violating effective type conditions. >> The second problem is basically The Law of Unintended Consequences >> smashing into The Law of Least Astonishment. As compiler writers >> have gotten more and more clever at exploiting the implications of >> "undefined behavior", we see more and more cases of code that looks >> reasonable being turned into mush by overly clever "optimizing" >> compilers. There is obviously something wrong with the way this >> trend is going -- ever more clever "optimizations", followed by >> ever more arcane compiler options to work around the problems >> caused by the too-clever compilers. This problem must be addressed >> by the C standard, for if it is not the ecosystem will transform >> into a confused state that is exactly what the C standard was put >> in place to avoid. (I do have some ideas about how to address this >> issue, but I want to make sure everyone appreciates the extent of >> the problem before we start talking about solutions.) > > Without specific examples , it's impossible to comment on this. > [...] I feel that so much has been written about this issue that it isn't necessary for me to elaborate. > 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). >> Before leaving the sub-topic of undefined behavior, let me mention >> two success stories. The first is 'restrict': the performance >> implications are local, the choice is under control of the program >> (and programmer), and the default choice is to play safe. Good >> show. > > 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. 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?