Re: Use of volatile const

Keith Thompson wrote:
However, I'm not convinced that Doug has got this one right. The
object z could be modified in some implementation-defined manner

But we know it isn't, because without the "volatile" the semantics
of the code are specified by the standard, and they are not affected
by the further qualification. It is unfortunate that the standard
was phrased in terms of "may be modified by ghosts" instead of "must
be physically read and written in strict accordance with the abstract
mashine model", which is the actual intent. Generally you have to
resort to non-strictly-conforming code to invoke any ghosts:
*(volatile short *)0xFFFF0FE0; // activates ghost controller
.

Relevant Pages

  • Re: mutex question
    ... Do you agree or disagree with my usage of sufficient, which has nothing much to do with your 'sufficient for externally observable reads and writes', by which I think you mean "triggers a memory read or write", without placing much in the way of semantics on those reads and writes. ... it is *not* necessary nor is it sufficient to use volatile on variables shared between threads.' ... C++ standard. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Use of volatile const
    ... I would like to have the simple guarantee that an object defined by the program, volatile or not, preserves its last value stored by the program, and the only ways to enable external "ghosts" that may modify the object behind the program's back are by using a non-conforming implementation or by doing something that makes the program's behaviour officially undefined by the C standard, such as calling a function not written in standard C, or converting an integer to a pointer, or declaring an object with a name that belongs to the reserved namespace. ... This would restrict the usefulness of "volatile" in portable code to the two situations were "volatile" is specifically required by the standard ), but I think that given that all other uses of "volatile" are not portable anyway, ... that would be better than making those two standard uses of "volatile", along with any other uses, officially non-portable by allowing conforming implementations to arbitrarily interfere with volatiles in a program unless you have made sure that you don't happen to have something implementation-specific in your environmant that enables the "ghosts". ... (Perhaps we could reach a compromise by inventing three categories of implementations: conforming without "ghosts", conforming with "ghosts", and non-conforming. ...
    (comp.std.c)
  • Re: Use of volatile const
    ... I would like to have the simple guarantee that an object defined by the program, volatile or not, preserves its last value stored by the program, and the only ways to enable external "ghosts" that may modify the object behind the program's back are by using a non-conforming implementation or by doing something that makes the program's behaviour officially undefined by the C standard, such as calling a function not written in standard C, or converting an integer to a pointer, or declaring an object with a name that belongs to the reserved namespace. ... This would restrict the usefulness of "volatile" in portable code to the two situations were "volatile" is specifically required by the standard ), but I think that given that all other uses of "volatile" are not portable anyway, that would be better than making those two standard uses of "volatile", along with any other uses, officially non-portable by allowing conforming implementations to arbitrarily interfere with volatiles in a program unless you have made sure that you don't happen to have something implementation-specific in your environmant that enables the "ghosts". ... (Perhaps we could reach a compromise by inventing three categories of implementations: conforming without "ghosts", conforming with "ghosts", and non-conforming. ...
    (comp.std.c)
  • Re: Is C99 the final C? (some suggestions)
    ... This would violate the division between preprocessor and compiler too ... much (the preprocessor would have to understand quite a lot of C semantics). ... ...This is legal C (as per the Standard), but it overflows the stack on ...
    (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)