Volatile is stupid

[Chris Torek]

>In article <12056 at mimsy.UUCP> I suggested that a worst case (not
necessarily the only one) is where a pointer is read in at runtime:
>>The key point here is that there is no algorithmic way to determine
>>volatility in this worst case---so any competent programmer must
>>assume that, if there are any volatile addresses, this code may refer
>>to one.  The programmer's only other option is to decree that the
>>program must never read an address that *is* volatile.  A programmer
>>who makes such a decree is certain to be surprised by a user. ...

In article <314 at accelerator.eng.ohio-state.edu> rob at kaa.eng.ohio-state.edu
(Rob Carriere) writes:
>What if the pointer ip is the output of another program, known to
>produce only non-volatile pointers?

Then the program will work fine for five years, and someone will install
it in an airplane controller, then someone else will manually `correct'
something, and your program will crash, along with the airplane.  This
is what correctness checking is all about.

>I know, the compiler.... That compiler is going to be rather sizable!

Yes, it will probably be enormous.  I doubt that I would want to use
it until computers are some orders of magnitude faster than they are
today.

>>`But wait!' you say.  `Even a very fancy optimising ``compiler''
>>(linker) is going to miss *some* things.  Why, we can use some fancy
>>mathematics to prove that it cannot catch everything.'
>>
>>That is so.  But how often will this occur in practise?  Today,
>>probably all the time; but tomorrow?  Five years from now?  Fifty?

>1) You started out by saying ``volatile'' is *useful* not *necessary*.
>   You have just admitted the fallacy of your own argument :-) 

Not really: I believe it is not necessary to get perfect optimisation:
enough that the difference is hard to notice is enough.  Any more is
unnecessary.  (In a way, *all* optimisation is unnecessary.  Useful
though. :-) )

>3) All this discussing boils down to: we have to tell the compiler
>   about the volitile things in life at *some* time, either when it's
>   born (your point of view),
(or at compile time, just before compiling the code)
>				or when it gobbles up my program (us
>   volatile types).  Well, *I* have to know as well (or I can't write the
>   code correctly) => from a readability point of view that means that
>   that information should be IN THE CODE.  Now, that's easy to achieve,
>   just add a keyword, say ``volatile''...

And if you have been reading all of my articles, I happen to agree.
I *like* the volatile keyword!  But I also like automatic volatility
detection.  A compiler that says

	"foo.c", line 1234: warning: *p may be volatile,
		but is not declared so

and then goes on to produce an incorrect program is *much* better than
one that simply produces the incorrect program.

And I think I shall say no more on that, at least for a few months.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris