Volatile is stupid

Steven Ryan smryan at garth.UUCP
Wed Jun 22 05:33:44 AEST 1988


>>>... Not only does this work, it is amenable to decent verification,
>>>management, configuration control, and maintenance.  "Volatile" is
>>>a hacker's answer.

What isn't a hack in Unix?

>>The compiler generally DOES NOT KNOW the address being accessed.
>
>And why not?  The answer is only that `the compiler' is too limited:

Inherently too limited.
 
>Ask the question this way:  Who calls dev_wait?  If you look at a
>PDP-11 kernel, it may look.....

Optimisers are essentially big bags of clever tricks. When some construct
sucks up enough runtime, somebody will figure a way to recognise it and
speed it up. Thus optimisers get better and better (and bigger and bigger)
BUT they are inherently limited.
 
>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.  If
>you meant that *ip had better not be volatile, you should check ip:

Hear! Hear! Safe programming means verifying each assertion about your input.
 
>`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.'

(Was it really that fancy? Godel incompleteness=Turing's halting problem.
Everybody should know the answer to that.)

I disagree that volatile is therefore stupid. That is a value judgement.
Dangerous? Perhaps. Unnecessary in many cases? Perhaps. Up to the user to
decide?



More information about the Comp.lang.c mailing list