From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Russ Cox" Date: Wed, 13 Sep 2000 14:06:07 -0400 To: 9fans@cse.psu.edu Subject: Re: [9fans] no const? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20000913180633.35E20199E0@mail> Topicbox-Message-UUID: 07104900-eac9-11e9-9e20-41e7f4b1d025 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