3 ms·
I've thought a lot about the restrict keyword since a month ago when you and I argued about this in the context of intentionally adding UB to Rust. I think you
by xscott 4y ago
I've thought a lot about the restrict keyword since a month ago when you and I argued about this in the context of intentionally adding UB to Rust.
I think you're wrong to conclude that UB was some kind of goal for "restrict" in C. As I remember it, there was a bit of envy in how Fortran compilers could make a few optimizations that C compilers could not. (Even now, some of the old-time Fortran advocates still trot this out as a reason Fortran is better) So C needed a way to say, "this function is more like Fortran now, go ahead and re-order the reads and writes if it helps". Thus "restrict" was born as a promise from the programmer to the compiler. The keyword mostly makes sense from that point of view, but of course there are devils in the details as shown in Ralf's article.
I haven't seen the mission statement, but there seems to be some agreement that the intent of the standards committee was to "codify existing practice" rather than define things on first principles or something. I'm sympathetic to the standard saying, "it's undefined to break your promise on this new feature we gave you".
As for why to make things like signed overflow undefined vs implementation defined, we could argue about it. If you've got a link to something more than speculation about that choice, I'd like to read it. My opinion shouldn't be terribly valuable to anyone.
> not using that tool suggests that the committee didn't want to require the compiler to do something "reasonable."
I believe it's a completely valid interpretation to treat undefined behavior as implementation defined. Maybe the whole point was, "Let them do what they want. The users can pick a different compiler if they want."
At this point, assuming the future standards mission is still to "codify existing practice", they'll probably keep listening to the compiler writers and programmers who prefer niche optimizations over sanity.
Btw, you should think about whether these optimizations are really that valuable. You're paying a cost, are you getting a benefit? Take a computationally intensive program you care about and recompile it with -frwapv. Don't just look at the assembly, measure the run time. Outside of some contrived example you don't really care about, I doubt you'll see much difference. And even if you do have an example you care about, I'm guessing it could be fixed by changing a 32 bit signed int to use a 64 bit array index.
- jcranmer 4y ago> As for why to make things like signed overflow undefined vs implementation defined, we could argue about it. If you've got a link to something more than speculation about that choice, I'd like to read it. My opinion shouldn't be terribly valuable to anyone. I'm (slowly) working on a "In Defense of UB" blog post, and I'm going to see if I can track down some old C committee members who might be able to offer more than speculation here. But I can't guarantee it, this is about discussions that happened well over 3 decades ago, and there's a good chance that recollections of details from that time are imperfect or just plain missing.
- xscott 4y agoI'll be eager to read that when you're done. I doubt I'll agree with your thesis, but still :-) I just went and skimmed the forward from an early version of "The C Programming Language" book [0]. There's certainly mention of writing portable programs, but UB as a device doesn't seem to be in there. And who knows what passed for "portability" in the early 70s - with enough preprocessor conditionals, you could have completely separate programs in the same file. > I'm going to see if I can track down some old C committee members I'll be interested in what they say, but any committee of more than one person is going to have varying beliefs and motivations. I'm sure you wouldn't do this, but it'd be possible to emphasize the examples that support your position while neglecting other view points. I also hope you'll at least consider Dennis Ritchie's perspective on the topic. Since he created the language, I think his opinion should carry more weight than most others. I haven't tracked the whole history of how "noalias" became "restrict", but he pretty clearly thought "noalias" was an "abomination" that created "hash of apparently safe programs". [1] At the very least, I think it shows he was opposed to making "hash" in the name of optimizations. I had no idea this debate has been going on since 1988. I guess compiler writers have been insane for much longer than I knew. [0] https://archive.org/details/TheCProgrammingLanguageFirstEdition/page/n9/mode/2up https://archive.org/details/TheCProgrammingLanguageFirstEdit... [1] https://groups.google.com/g/comp.lang.c/c/K0Cz2s9il3E/m/YDyo_xaRG5kJ https://groups.google.com/g/comp.lang.c/c/K0Cz2s9il3E/m/YDyo...