This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: volatile semantics
- From: "D. Hugh Redelmeier" <hugh at mimosa dot com>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: gcc at gcc dot gnu dot org, Nathan Sidwell <nathan at codesourcery dot com>, Dale Johannesen <dalej at apple dot com>, Mike Stump <mrs at apple dot com>
- Date: Sat, 16 Jul 2005 15:19:45 -0400 (EDT)
- Subject: Re: volatile semantics
- References: <851D2CB0-93DF-4C49-A6A8-8895DB1A08F9@apple.com> <42778D99.7070904@codesourcery.com> <b0f8ff9938df57bbfda0ec3aea4fc02b@apple.com> <Pine.LNX.4.61.0507161250120.1478@redshift.mimosa.com><1121532997.29893.6.camel@linux.site>
- Reply-to: "D. Hugh Redelmeier" <hugh at mimosa dot com>
[I'm just a tourist here. I don't subscribe to the gcc list. I don't
hack on gcc itself. I'm just posting because this bug hits me and
didn't seem to be analyzed correctly. I have participated in the C
standardization process for perhaps 20 years. Now that I look at the
GCC list archives, I see a more of misunderstanding of the standard
than I'd like.]
| From: Daniel Berlin <dberlin@dberlin.org>
[quoting Henry's comment]
| > 6.5.3.2: applying `*' to a pointer of type `T *' which points to an
| > object yields an lvalue of type `T' designating that object. So the
| > lvalue in the assignment has a volatile-qualified type.
| >
| > 6.3.2.1: when an object is said to have a particular type, the type is
| > specified by the lvalue used to designate the object. So the lvalue
| > having a volatile-qualified type *means* that the object it designates has
| > a volatile-qualified type; "has type X" and "is designated by an lvalue of
|
| How does this reasoning not apply to *((char *)a) = 5 where a was
| originally of a const qualified type?
Did you read Henry's comment in full? It specifically addresses
"const".
Surprising though it might seem, I see no express or implied permission to
distinguish based on whether the object in question was *defined* with a
volatile-qualified type. There are places in the standard where how an
object is defined is significant, e.g. the rules for `const' and the part
of 6.7.3 noted in the previous paragraph, but none of them is part of the
chain of reasoning above.
| Or do you think you can only *add* qualifiers, and not remove them?
No, that was not said.
| Because if you allow casting away, then you can't ever trust const to be
| true either, just like we apparently can't trust the user saying "this
| is not volatile" (which they are doing by not declaring the original
| object volatile).
No, that is not correct reasoning.
"const" says: this lvalue will only be used for reading. It does not
say that the underlying object will not be changed. More is implied
if the object in question is *defined* with a const attribute. For
example:
const int foo = 0xF00;
| There is no point in type qualifiers if they can be simply changed at
| will.
This has an element of truth to it. But they do have points:
- const means that a program cannot accidentally change something
through a const-qualified thingee (lvalue, pointer, whatever)
- volatile tells the compiler "hands off" when such an lvalue is used.
- let's not talk about "restrict"
| Do not lie about your objects, and you will not be screwed over.
Funny that you should be paraphrasing one of Henry's famous aphorisms
"If you lie to the compiler, it will get its revenge.". Yes, this is
the same Henry Spencer.