This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: volatile semantics


[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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]