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