Re: [9fans] no const?

["Russ Cox" <rsc@plan9.bell-labs.com>]

I don't know anything officially but what I understand is...

In the Plan 9 compilers, volatile is mostly unnecessary.
Treating all variables as callee-save has the side effect
of taking care of setjmp and longjmp.  I believe pointers
are always dereferenced (i.e. multiple *p's will never get
coalesced into a single dereference or lifted out of a loop).
Those are the two main needs for volatile, gone, at the
price of a little optimization, as was pointed out.

When I tried to port drawterm (basically a stripped down
Plan 9 kernel) to Digital Unix, I had a bear of a time putting
the volatiles in the right places, until I found the -volatile
compiler flag to make everything volatile.  This is basically
what the Plan 9 compiler does.

In the case of const, it is harder to justify both its 
necessity and its omission.  It's hard to explain to people,
and as Forsyth points out, adds little serious protection.
It's also not too hard to implement, and indeed the compilers
do implement it now.  The lack of necessity is really the 
best justification for the omission.  The C type system is
not particularly expressive, but adding little warts like
const or restrict, whatever that means, just sullies it without
any real benefit.  Boyd is right that it certainly feels like
such things have been added as a sacrifice to the god of 
efficiency rather than for use by mere mortals.

And it is a fact that const and volatile are not easily
understood.  Try explaining to a beginning C programmer
why "volatile Chan *c" or "Chan volatile *c" both declare
a pointer to a volatile Chan structure rather than a 
volatile pointer to a Chan structure (which would, obviously,
be "Chan *volatile c").

Russ