[9fans] no const?

[9fans] no const?

[David L Rubin]

http://plan9.bell-labs.com/sys/doc/comp.html states

"The compilers do their own register allocation so the register keyword
is ignored. For different reasons, volatile and const are also ignored."

This is a bit mysterious...why are volitile and const ignored?

	david

~~
David L Rubin <davidrubin@lucent.com>   f/973.581.6665  
v/973.386.8598   
Lucent Technologies, NJ0117 15G-117, 67 Whippany Rd, Whippany, NJ 07981
temporary voice mail: +34 91.807.1054

Re: [9fans] no const?

[Boyd Roberts]

----- Original Message ----- 
From: "David L Rubin" <rubin@redconnect.net>
> 
> This is a bit mysterious...why are volitile and const ignored?
> 

'cos they were stupid, unnecessary, incomprehensable language abortions.

Re: [9fans] no const?

[Douglas A. Gwyn]

Boyd Roberts wrote:
> From: "David L Rubin" <rubin@redconnect.net>
> > This is a bit mysterious...why are volitile and const ignored?
> 'cos they were stupid, unnecessary, incomprehensable language abortions.

Sounds like you don't understand them.  What alternative to
volatile does the Plan 9 compiler offer?  Crippled optimization?

"const" can be ignored by the compiler without adversely
affecting any strictly conforming program, but by doing so
a valuable diagnostic is lost (for a function that is not
supposed to modify the object one of its arguments points
to, but does).  const also allows data to be placed in ROM
or I address space, for compilers that grok that.

Re: [9fans] no const?

[Boyd Roberts]

From: "Douglas A. Gwyn" <DAGwyn@null.net>

> Sounds like you don't understand them.  What alternative to
> volatile does the Plan 9 compiler offer?  Crippled optimization?
> 

it's a self evident proof that plan 9 works without them.

the mess you can make with those 'storage classes' is not understandable.

that little tin god efficiency -- henry spencer.

Re: [9fans] no const?

[Steve Kilbane]

Classic Boyd:
> it's a self evident proof that plan 9 works without them.

Sigh, no. You can't prove it works. You can only prove it hasn't
broken so far.

As for unnecessary, this is also true of most things in the language.
Indeed, it's true of the language itself, but that's taking things to
ridiculous levels. The question is, are they worthwhile? I.e., does the
effort of putting them into the compiler pay off in bug avoidance?

> the mess you can make with those 'storage classes' is not understandable.

Question: are you arguing against the concepts of volatile and const,
or against their meanings in ANSI C?

steve

Re: [9fans] no const?

[Boyd Roberts]

From: "Steve Kilbane" mailto:steve@whitecrow.demon.co.uk
> Classic Boyd:
> > it's a self evident proof that plan 9 works without them.
>
> Sigh, no. You can't prove it works. You can only prove it hasn't
> broken so far.

yes, i do know that one.  but, i does work without them  there is
a subtle difference.  ie. they were unnecessay, whereas 'if' is
indispensable.

> Question: are you arguing against the concepts of volatile and const,
> or against their meanings in ANSI C?

the real problem is how it was done in ANSI C.  i've got nothing against
constants.  i've even been known to use the odd constant, but never
a 'const' :-).

volatile?  yeah, i remember times when i coulda used it.  like in the 8th ed
tu-16 tape driver that john mackin and i fixed.  volatile would been nice,
but we fixed it with a macro (no assembler).

i don't see that polluting the language in such a deplorable way is valid.

well it wouldn't be me if it wasn't 'Classic Boyd'...

Re: [9fans] no const?

[Douglas A. Gwyn]

Boyd Roberts wrote:
> the real problem is how it was done in ANSI C.  i've got nothing
> against constants.  i've even been known to use the odd constant,
> but never a 'const' :-).

Since "const" doesn't mean "constant", again it's evident that
you're criticizing something that you do not understand.

> volatile?  yeah, i remember times when i coulda used it.  like in
> the 8th ed tu-16 tape driver that john mackin and i fixed.
> volatile would been nice, but we fixed it with a macro (no assembler).

I don't know the specific problem you encountered, but the PDP-11
PCC had a specific hack to disable optimization for certain kinds
of access that could be identified as potentially within the I/O
page.  I don't recall whether Ritchie's compiler performed the
optimization in the first place.

> i don't see that polluting the language in such a deplorable way
> is valid.

If you had better suggestions for how to address the same issues,
the C standards committee would have been glad to hear them.
It's easy to complain about what others do, but also pointless.

Re: [9fans] no const?

[Boyd Roberts]

----- Original Message ----- 
From: "Douglas A. Gwyn" <DAGwyn@null.net>
 
> Since "const" doesn't mean "constant", again it's evident that
> you're criticizing something that you do not understand.

i know what i means; this value/object cannot be modified.
you could use it with the arg to strlen; a pointer to const char.
if you really wanna smash memory 'const' will not save you;
say you malloc the arg to strlen.  later on (not in strlen) you could
smash it.  const overly complicates the language and adds little value.

> > volatile?  yeah, i remember times when i coulda used it.  like in
> > the 8th ed tu-16 tape driver that john mackin and i fixed.
> > volatile would been nice, but we fixed it with a macro (no assembler).
> 
> I don't know the specific problem you encountered, but the PDP-11
> PCC had a specific hack to disable optimization for certain kinds
> of access that could be identified as potentially within the I/O
> page.  I don't recall whether Ritchie's compiler performed the
> optimization in the first place.

hmm, 8th ed ran on VAXen, not 11's; only about 10 licences
were granted.  but, it was some 16 bit reference in the interrupt routine.
8th ed was based on 4.1BSD and so i don't rightly recall what compiler
it was running.  ken should know.

> It's easy to complain about what others do, but also pointless.

really?   criticism serves no purpose?  nonsense.

Re: [9fans] no const?

[Steve Kilbane]

> > Sigh, no. You can't prove it works. You can only prove it hasn't
> > broken so far.
> 
> yes, i do know that one.

that's all right, then. we'll ignore the "proof" thing, then. :-)

> but, i does work without them  there is
> a subtle difference.  ie. they were unnecessay,

Again, no. *you* might not need them. Plus, of course, there's the
distinction between Plan 9 the operating system, and Plan 9 as an
environment. Application programmers are traditionally less sophistocated
than kernel developments, and the ratio of support tools varies accordingly.

> whereas 'if' is
> indispensable.

Uh-uh. 'if' in C is a lot easier than coding in assembler with branches,
but indispensible? The trade-off is just more noticable to you. There's
an IOCCC entry, IIRC, that avoids 'if' completely.

In other words, it's a subjective thing.

> > Question: are you arguing against the concepts of volatile and const,
> > or against their meanings in ANSI C?
> 
> the real problem is how it was done in ANSI C.  i've got nothing against
> constants.  i've even been known to use the odd constant, but never
> a 'const' :-).

Well, I can't argue beyond this point: I know that 'const' in ANSI C
doesn't mean quite what it should, and avoid using it for that reason
(I particularly dislike not being able to remember whereabouts in the
decl the damn thing should appear).

> well it wouldn't be me if it wasn't 'Classic Boyd'...

I can argue with this one, too... :-)

steve

Re: [9fans] no const?

[Douglas A. Gwyn]

Boyd Roberts wrote:
> if you really wanna smash memory 'const' will not save you;
> say you malloc the arg to strlen.  later on (not in strlen) you could
> smash it.

If the malloced pointer is stored in a properly declared variable,
then subsequent attempts to modify the pointed-to storage result
in a diagnostic.  Since the actual dynamic storage is not inherently
read-only, that is the best that one could hope for from the language.

> > It's easy to complain about what others do, but also pointless.
> really?   criticism serves no purpose?  nonsense.

No, complaining serves no purpose.  Critiquing can be useful if
the analysis uncovers some interesting principles or facts.

Re: [9fans] no const?

[Boyd Roberts]

From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
> 
> If the malloced pointer is stored in a properly declared variable,
> then subsequent attempts to modify the pointed-to storage result
> in a diagnostic.  Since the actual dynamic storage is not inherently
> read-only, that is the best that one could hope for from the language.

hope?  i don't see the point of adding a buncha extra code to the
compiler in the 'hope' that things will be better.

> No, complaining serves no purpose.  Critiquing can be useful if
> the analysis uncovers some interesting principles or facts.

oh semantics...

Re: [9fans] no const?

[Theo Honohan]

In article <019c01c01f08$eecbb1a0$89c584c3@cybercable.fr>,
Boyd Roberts <9fans@cse.psu.edu> wrote:
>From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
>> 
>> If the malloced pointer is stored in a properly declared variable,
>> then subsequent attempts to modify the pointed-to storage result
>> in a diagnostic.  Since the actual dynamic storage is not inherently
>> read-only, that is the best that one could hope for from the language.
>
>hope?  i don't see the point of adding a buncha extra code to the
>compiler in the 'hope' that things will be better.

You've got to be trolling, now.  By "the best (protection) that one
could hope for", DAG obviously means "the best (protection) that is
obtainable".

Re: [9fans] no const?

[Boyd Roberts]

From: "Theo Honohan" <theoh@chiark.greenend.org.uk>
> >hope?  i don't see the point of adding a buncha extra code to the
> >compiler in the 'hope' that things will be better.
> 
> You've got to be trolling, now.  By "the best (protection) that one
> could hope for", DAG obviously means "the best (protection) that is
> obtainable".

if that's what he meant he should have used a more precise construction.

hope and code just don't mix.  like pointer and integer; it might work
most of the time [hope], but it's wrong.

btw:  DAG is pretty funny in oz slang :-)

Re: [9fans] no const?

[Steve Kilbane]

Doug:
> No, complaining serves no purpose.  Critiquing can be useful if
> the analysis uncovers some interesting principles or facts.

Agreed. "This is bad" doesn't help. "This is bad because X" does.

steve

Re: [9fans] no const?

[Matt Lawless]

> if that's what he meant he should have used a more precise construction.


oh semantics...

:-)

Re: [9fans] no const?

[Douglas A. Gwyn]

Steve Kilbane wrote:
> Well, I can't argue beyond this point: I know that 'const' in ANSI C
> doesn't mean quite what it should, and avoid using it for that reason
> (I particularly dislike not being able to remember whereabouts in the
> decl the damn thing should appear).

"const" does mean what it should, just as "char" means what it should.
The names may be misleading if you have no other clue, but you're not
supposed to be guessing about the language.

The "const" qualifier goes next to the thing it qualifies.
How hard is that rule to remember?
	const int *p;	// pointer to const int
	int const *p;	// pointer to const int
	int *const p;	// const pointer to int

Re: [9fans] no const?

[Douglas A. Gwyn]

Boyd Roberts wrote:
> From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
> > If the malloced pointer is stored in a properly declared variable,
> > then subsequent attempts to modify the pointed-to storage result
> > in a diagnostic.  Since the actual dynamic storage is not inherently
> > read-only, that is the best that one could hope for from the language.
> hope?  i don't see the point of adding a buncha extra code to the
> compiler in the 'hope' that things will be better.

Your response has nothing to do with what I said.  At this point
I have to conclude that your mind is already made up and you
don't want to be confused with the facts.

Re: [9fans] no const?

[Douglas A. Gwyn]

Russ Cox wrote:
> Those are the two main needs for volatile, gone, at the
> price of a little optimization, as was pointed out.
> ...
> compiler flag to make everything volatile.  This is basically
> what the Plan 9 compiler does.

Of course, implementors are free to do that.  The reason
they tell me that they don't usually is that many of their
customers demand more aggressive optimization (without the
programmer having to edit source code to get it).  If that
is not important to Plan 9 goals, then its approach is fine
and the "volatile" keyword can then in effect be a no-op.

> In the case of const, ... it certainly feels like
> such things have been added as a sacrifice to the god of
> efficiency rather than for use by mere mortals.

I use "const" frequently, and not because I expect any
additional optimization.  Rather, it documents one
important property of some parameters etc. and enables
diagnostics that routinely detect a certain class of bugs
(which would be undetectable without some programmer-
supplied indication of the intent in the source code).

> 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").

That's just a problem in understanding Dennis's contextual
design for C type declarations in general, and is no harder
to explain than anything else of a similar sort in C.

Re: [9fans] no const?

[Russ Cox]

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

Re: [9fans] no const?

[Douglas A. Gwyn]

forsyth@vitanuova.com wrote:
>         volatile: both too little and too much to be useful for the purpose for which it is touted
>         const: confuses the C type system but does not seriously add clarity or protection
>                         (eg, char *strchr(const char *, int))

Those complaints are essentially the same: that the facility
addresses some problems but not all related problems.  This
aspect was well understood when we adopted them for the first
C standard in the 1980s, and the decision was based on getting
some benefit some of the time rather than getting no benefit
all of the time.

Note that the new C standard adds restrict qualification for
pointers, to allow optimizations that otherwise would not be
safe.  "restrict" can be ignored by the compiler, so long as
it doesn't try to make those aggressive optimizations.

Re: [9fans] no const?

[forsyth]

i suspect the answers are along the lines of disapproval sparked by:
	volatile: both too little and too much to be useful for the purpose for which it is touted
	const: confuses the C type system but does not seriously add clarity or protection
			(eg, char *strchr(const char *, int))
although the compilers now pay more attention, at least when type checking,
when const, volatile and register appear than that paper suggests.

Re: [9fans] no const?

[Boyd Roberts]

----- Original Message ----- 
From: "Russ Cox" <rsc@plan9.bell-labs.com>

> They are neither stupid nor unnecessary.

so why did ken chuck 'em and why does plan 9 not need them?

Re: [9fans] no const?

[miller]

> This is a bit mysterious...why are volitile and const ignored?

In fact they aren't.  Compilers (if invoked with '-w') will give a warning
message on assignment to identifiers declared const.  And volatile declarations
do influence the register allocation algorithm.

-- Richard Miller

Re: [9fans] no const?

[Russ Cox]

	'cos they were stupid, unnecessary, incomprehensable language abortions.

They are neither stupid nor unnecessary.