I had a hard time following Ritchie’s argument. I guess I’m missing a lot from the proposals he’s critiquing. One part stood out that was not clear:<p>> memcpy(noalias void *s1, const noalias void *s2, size_t n);<p>> what information can one glean from it? Some committee members apparently believe that it conveys either to the reader or to the compiler that the routine is safe, provided that the strings do not overlap. They are mistaken.<p>I don’t follow. It seems that noalias exactly means that the two arrays can never point to the same memory, thus they do not overlap. So why would it be wrong to assume that memcpy() with noalias arguments is safe if called with non-overlapping memory?<p>————<p>Separately I agree with him that “noalias” unlike “const” is not a property of the object being pointed to but rather a property of the access being done. It creates an inconsistency where “char * noalias” makes sense but “char noalias” doesn’t. Perhaps he would have supported a “noalias dereference” operator or compiler built-in instead.
blogspam for <a href="https://groups.google.com/g/comp.lang.c/c/K0Cz2s9il3E/m/YDyo_xaRG5kJ" rel="nofollow">https://groups.google.com/g/comp.lang.c/c/K0Cz2s9il3E/m/YDyo...</a>
Then 10 years later <i>restrict</i> was born with many of the same caveats that Dennis Ritchie refers to <i>noalias</i>.<p>A good example of when language authors no longer control its direction, rather the standards body.
“a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs”<p>That phrase, describing ‘noalias’, proves that nobody at the time realized or intended what “undefined behavior” would turn out to mean.