
How to Use the Plan 9 C Compiler [pdf] - vezzy-fnord
http://plan9.bell-labs.com/sys/doc/comp.pdf
======
kr7
I have stopped using #ifdef entirely in favor of #if. The problem with #ifdef
is it will silently ignore a misspelled argument. If you use #if in
conjunction with the -Wundef flag it will catch it.

This can be a major security vulnerability if the #define is enabling a
security feature but it gets silently disabled because of a misspelling.

------
saysjonathan
HTML version:
[http://doc.cat-v.org/plan_9/2nd_edition/papers/comp](http://doc.cat-v.org/plan_9/2nd_edition/papers/comp)

------
i4k
Ken Thompson's C Compiler:
[http://doc.cat-v.org/bell_labs/new_c_compilers/new_c_compile...](http://doc.cat-v.org/bell_labs/new_c_compilers/new_c_compiler.pdf)

------
fredkbloggs
This is not a C compiler; the language it accepts bears only a superficial
resemblance to any version (formally standardized or not) of C. The subset of
C's original authors responsible for this needed to accept that C was both (a)
extremely popular and successful and (b) to their way of thinking, inferior to
what they would have wished. That's a tough place to be, but denial is worse.

~~~
stonogo
Is there a particular reason that "using a subset of ANSI C" is morally worse
than "inventing an entirely new language"? I think you're maybe ascribing some
kind of ethical purity to ANSI that it doesn't really have, especially given
the popularity of GNU extensions et al.

~~~
fredkbloggs
I'm drawing a distinction between adding extensions (which can still be
problematic if they can't be disabled) and ignoring or rejecting parts of the
language that are required for correctness. The simplest and most obvious
example mentioned fairly early in the paper is const but there are plenty of
others.

I can compile nearly any C program using gcc and get correct behavior.
Obviously I can also compile a lot of other things using gcc, including things
that are not found in C, and if I do so then I cannot expect any definition of
C to specify the resulting behavior. But most C programs will not compile
using the Plan 9 compilers at all, because they do not accept the C language
by any meaningful definition. In the case of const, it's also true that many
dangerously incorrect programs will compile when using Plan 9's compiler, even
though any definition of C prohibits that explicitly. These are qualitative
differences.

Let's be even more concrete. In case 1, we consider a language exactly like C
(pick whatever C you want here), but with the following additional
preprocessor symbols always defined:

    
    
        #define _FBEGIN {
        #define _FEND }
    

This language allows, but does not require, the use of alternate tokens
instead of { and } around function bodies. Because the tokens are taken from a
namespace reserved by the standards, every correct C program is also a correct
program in this language, and will have the same behavior. I submit that one
may reasonably claim that a compiler for this language is a C compiler that
supports extensions, even though a very limited subset of incorrect programs
will fail to compile in a different way than they would when submitted to a C
compiler.

In case 2, we consider the same language except that in this case the use of {
and } around function bodies is not accepted. Instead, one _must_ use _FBEGIN
and _FEND. I submit that a compiler for this language is not a C compiler, as
no (useful) correct C program is accepted by it.

What the Plan 9 compiler authors did, repeatedly, reduces to case 2. There is
nothing unethical about creating a new language. There is something unethical
about creating a new language and not only deliberately giving it the same
name as a similar (very popular) language, but disingenuously acting as if it
_were_ that language. At best, the implication that all other (again, very
popular) standards and implementations of C are wrong simply for not being
Plan 9's is obnoxiously smug.

~~~
vezzy-fnord
Your entire rant is protracted and without substance. It boils down to
comparing 9c to gcc and concluding that the former is not a C compiler
relative to the standards of the latter. In which case, tcc, pcc and ACK would
also be disqualified as C compilers under your definition.

~~~
fredkbloggs
gcc is merely an example of a C compiler. Feel free to substitute the Intel
compilers, the Microsoft compilers, or just about any real-world compiler that
gets used to ship real products. In other words, any actual C compiler.

------
swolchok
> For different reasons, volatile and const are also ignored.

Yikes.

~~~
mikeash
Const is mildly useful but doesn't do a whole lot. It's as much of a reminder
to the programmer as anything.

Volatile's behavior is not really defined by the standard and is rarely useful
in any case. I'm pretty sure that you can ignore it and remain a fully
compliant C compiler.

~~~
Sir_Cmpwn
volatile is mostly useful for telling the compiler not to optimize out a
variable. For example, if you use memory-mapped I/O, you can mark a pointer to
it as volatile to tell the compiler that the hardware will be changing it and
it shouldn't make any assumptions about that while optimizing. That's lower
level than most people go, though, so I understand that it's not useful for
the average C programmer.

~~~
plorkyeran
Plan 9's compiler does not have a very sophisticated optimizer (which is part
of why it's so fast), so I suspect that they simply didn't implement anything
which would have made volatile necessary.

~~~
mikeash
Right, if every assignment writes to memory and every expression reads from
memory then you've effectively made every variable volatile (according to how
compilers typically interpret volatile), so ignoring the qualifier wouldn't
hurt anything.

