From mboxrd@z Thu Jan 1 00:00:00 1970 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (1.0) From: Brantley Coile In-reply-to: <1448274004.1751482.447419065.2BE466C4@webmail.messagingengine.com> Date: Mon, 23 Nov 2015 06:50:08 -0500 Content-transfer-encoding: quoted-printable Message-id: <6B7DA7E3-3917-4A67-9084-1B5DD90D97F9@me.com> References: <1448274004.1751482.447419065.2BE466C4@webmail.messagingengine.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Undefined Behaviour in C Topicbox-Message-UUID: 76de5910-ead9-11e9-9d60-3106f5b1d025 This is an interesting issue to me because I'm becoming more and more aware o= f a fundamental misunderstanding of C which will make it difficult for peopl= e to write efficient code in the future. These two documents show a lack of u= nderstanding regarding the reason for undefined behavior and a confusion bet= ween undefined specification and undefined behavior.=20 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 beh= avior to great detail and as a result was very inefficient on some architect= ures. C avoided these inefficiencies by letting the machine do what was natu= ral. Loading a character into an integer register is an example. It is undef= ined 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 s= ome architectures.=20 Leaving these aspects to the local machine was one of the places where Denni= s' genius shows through. And it's why they could write and operating system i= n 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 o= ne reason.) Ken's compiler does the right amount of optimizations, limiting them mostly t= o what the programmer can't fix. The idea that a C compiler can be smarter t= han a sloppy programmer is causing compilers to be unusable for what I do. T= hese bloated compilers can never be idiot proof because idiots are so ingen= ious. The beauty of C is that one can write a simple compiler and create ver= y fast code by being a good programmer. Give me smart programmers and simple= compilers and not dumber programmers and idiot savant, and bloat, compilers= .=20 So C, as it is now defined, is in no need of fixing. The MIT paper has a confusion between the undefined specification and undefi= ned behavior. If you load a character into an integer, sign behavior is unsp= ecified. But how many people program 8086 large model code any more, the rea= son 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 s= ome other architecture, it's broke.=20 To write fast code one need a simple notation and a simple predictable compi= ler. Ken's C compiler fits this requirement to a tee.=20 Sent from my iPad > On Nov 23, 2015, at 5:20 AM, Ramakrishnan Muthukrishnan wrote: >=20 > Had been reading the SOSP paper: > >=20 > and this blog post that proposes a simpler C: > >=20 > 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. >=20 > --=20 > Ramakrishnan >=20