Re: Use of volatile const

Douglas A. Gwyn wrote:
James Kuyper wrote:
Douglas A. Gwyn wrote:
The standard already specifies that the accesses must actually
occur, *whether or not a ghost is at work*.
True; but that's not the issue. The issue is what the access will find;
because the standard allows for (as you put it) ghostly intervention,
the access may retrieve a different value from the one last written.
There's no reasonable way for that to happen, but the standard only
requires that the object's definition be volatile-qualified, in order to
allow "ghostly intervention". It doesn't impose other requirements, such
as initializing a pointer to volatile qualified memory with an
implementation-defined special value, or with the return value from an
implementation-defined routine. It simply says "volatile qualified".

My point is that the rest of the standard is still applicable,
and it includes a virtual machine model, sequence points, etc.
Volatile qualification, which can be applied in ways other than
just in object definitions, limits the extent to which the
generated code can deviate from the abstract execution model.

What that rest of the standard says about the virtual machine model,
sequence points, etc, is not sufficient to ensure that the following
code has defined behavior:

int main(void) {int i=0; return i;}

Only 6.2.4p2 guarantees that, when the return statement is reached,
'i' will retain it's last-stored value, in this case 0, which is a
value with defined behavior for a return statement. However, 6.7.3p6
explicitly modifies that guarantee with respect to any object with
volatile-qualified type. As Footnote 26 puts it, "In the case of a
volatile object, the last store need not be explicit in the program."
This means that in principle

int main(void) {volatile int i=0; return i;}

might not have defined behavior, because a store which is not
explicitly in the program might have changed the value of 'i' to one
which cannot be safely used in a return statement.

I didn't understand your last couple of sentences, since I never
said anything about implementation-defined special values etc.

I was just giving examples of plausible ways in which a program could
gain access to truly-volatile memory. My point is, the standard should
clarify what those methods are. As written it says that simply
applying the 'volatile' qualifier to an object declaration is
sufficient to enable stores which are not explicit in the program; and
I'm sure that this was not the intent.
.

Relevant Pages

  • Re: ANSI C question about volatile
    ... > context related to 'volatile'. ... > volatile int x; ... I'm asking only what the standard ... On the other hand, if you want references to portions of the standard, ...
    (comp.lang.c)
  • Re: size_t problems
    ... Schildt, as just one example, wrote The Annotated ANSI C Standard, a book ... his strcount function returns an int, ... absolute strict correctness for clarity and vice versa. ... make the risks involved in that decision explicit to the reader. ...
    (comp.lang.c)
  • Re: Volatile in C99
    ... I realize that's your opinion; ... Yes as it is your opinion not everyone's that an access to volatile ... referred to several different sections of the Standard, ... unknown side-effects may be. ...
    (comp.std.c)
  • Re: question about k&r2
    ... it is assumed to return int. ... _more_ sense to leave out an explicit int than to put one in for ... Of course, K&R2 was supposed to be about the new standard, ... There is still no requirement in C99 for a non-void function ...
    (comp.lang.c)
  • Re: Volatile in C99
    ... written so as not to need volatile for such cases. ... but saying setjmpcan be used in a strictly conforming ... fact solely by the text of the standard, which is the reason I said ... the wording should be clarified. ...
    (comp.std.c)
Loading