This is an interesting issue to me because I'm becoming more and more aware of a fundamental misunderstanding of C which will make it difficult for people to write efficient code in the future. These two documents show a lack of understanding regarding the reason for undefined behavior and a confusion between undefined specification and undefined behavior.
Efficiency is the reason for undefined specification. The objective of C was to replace assembler language without giving up the ability to write tight, efficient programs. Other languages, such as ALGOL, had defined all the behavior to great detail and as a result was very inefficient on some architectures. C avoided these inefficiencies by letting the machine do what was natural. Loading a character into an integer register is an example. It is undefined in C whether or not it sign extends or not. Some machines do it one way, some another. To force the language to one behavior requires more code on some architectures. Leaving these aspects to the local machine was one of the places where Dennis' genius shows through. And it's why they could write and operating system in C and have it run quite well on a tiny minicomputer while Multics with its PL/1 language was dog slow on a huge expensive mainframe. (Okay, it's only one reason.) Ken's compiler does the right amount of optimizations, limiting them mostly to what the programmer can't fix. The idea that a C compiler can be smarter than a sloppy programmer is causing compilers to be unusable for what I do. These bloated compilers can never be idiot proof because idiots are so ingenious. The beauty of C is that one can write a simple compiler and create very fast code by being a good programmer. Give me smart programmers and simple compilers and not dumber programmers and idiot savant, and bloat, compilers. So C, as it is now defined, is in no need of fixing. The MIT paper has a confusion between the undefined specification and undefined behavior. If you load a character into an integer, sign behavior is unspecified. But how many people program 8086 large model code any more, the reason for the comment into the standard? I 'm not an expert on gcc, in fact I know more that I really want to about it. But, if it tosses code like buf + len < size, because it might be wrong on some other architecture, it's broke. To write fast code one need a simple notation and a simple predictable compiler. Ken's C compiler fits this requirement to a tee. Sent from my iPad > On Nov 23, 2015, at 5:20 AM, Ramakrishnan Muthukrishnan <r...@rkrishnan.org> > wrote: > > Had been reading the SOSP paper: > <https://pdos.csail.mit.edu/papers/stack:sosp13.pdf> > > and this blog post that proposes a simpler C: > <http://blog.regehr.org/archives/1180> > > I wonder how Plan 9 C compiler, which is a non-ANSI compliant compiler, > treats those parts that the ANSI C standard treats as undefined. > > -- > Ramakrishnan >
