Re: Volatile in C99

woong@xxxxxxxxx writes:

Tim Rentsch <t...@xxxxxxxxxxxxxxxxxxx> wrote:
Jun Woong <wo...@xxxxxxxxx> writes:
[...]

Yes, but with a huge loss in its usefulness and/or flexibility.

I realize that's your opinion; not everyone shares that
opinion.


Yes as it is your opinion not everyone's that an access to volatile
object may cause a program to behave in a non-conforming way.

The difference is, I've cited portions of the Standard that
directly support my interpretation. You might think they are
poorly worded, and perhaps they are, but certainly they exist,
and certainly they bear on the issue. It's true that you have
referred to several different sections of the Standard, but none
of them have any sort of definite bearing on the issue, let alone
offer your view any direct support.


Anyone,
however, who has implemented a general exception-handling mechanism
using the non-local jump facility would agree with my opinion.

Another opinion unsupported by any evidence. And even if it
were, any such opinions still wouldn't change what the Standard
says. Do you understand that the only question that matters
in this discussion is what the Standard says on the topic?
And in particular, not on what anyone else says, or thinks,
or whatever.


[...]
And let me put my words anther way. Suppose that we're writing the
specification for the non-local jump facility. Things goes well so
that s.c. code has no problem in using it, but a problem that is
providing a way to keep a value of a local object modified between
setjmp and longjmp. Since a non-trivial use of the non-local jump
requires the way, employing an existing language feature that
certainly renders code using it non-conforming will bring to the
effort put in so far to naught. Nevertheless, should we think that
the committee chose "volatile" for that purpose even if they knew
well any use of it turned otherwise portable code to non-conforming
one?

Generally I find it isn't helpful to think about what the committee
was thinking, except to suggest different ways of parsing some
particular text. More succinctly, considering the committee's
intentions sometimes help suggest ways a passage /might/ be read, but
doesn't help determine how a passage /should/ be read. So I don't
think your question illuminates the issue here.


The standard is a means for the committee to express their intent.
Idealy it has to deliver that without any ambiguity, but
unfortunately there are some unclear wordings (like one we're
discussing) whether or not it's intentional. In such a case, it is
helpful to try to figure out what the intent is, rather than to stick
with the wording in question, since it would be revised to reflect
the intent when clarified by request.

I spoke to this issue already in the previous posting. Did you
not understand what I said?


[...]

There are some in fact:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n732.htm

which is reflected to C99's term definitions.

Even if we accept that the scope of "implementation-defined" is
limited in the sense proposed in this document, it's still true
that there are no clear boundaries as regards volatile, because
it isn't clear what possibilities the Standard "provides". It's
not what "implementation-defined" means that's in question; it's
what "what constitutes an access" is allowed to mean that's in
question.


Unreasonable. The thing, "what constitutes an access", that you think
important gains its latitude by the following wording
"implementation-defined," and is also restricted by the same wording
at the same time.

I suggest you stick to simpler sentence constructions. As
English that last sentence is pretty much gibberish.


An implementation-defined thing itselt is not
allowed to let a conforming implementation to behave in a non-
conforming manner.

As long as choice of behavior is within the set of allowed
choices, and as long as the implementation documents that choice,
the result is by definition still conforming.


Thus, for a volatile access to make a program
containing it invalid as system() or #pragma can do, its wording
should say something like what the wordings for system() and #pragma
say.

The mechanisms are different. There is no reason to suppose
their descriptions should be worded similarly. A key difference
is that, for #pragma and system(), the possibility of undefined
behavior depends on the particulars of the implementation-defined
behaviors associated with them, including a requirement to
document those behaviors. For volatile access, the possibility
of undefined behavior doesn't depend on implementation-defined
behavior.


The only thing that the standard specifies for an volatile
access is that the accessed object may be modified by an agent unseen
to a program and that the access may have unknown side effect, but
with "implementation-defined" the "unknown and unseen" thing is not
free to go to spoiling the normal execution of a conforming program.

Sorry, but it is. The Standard places no limits on what the
unknown side-effects may be. Not only that, but in some real
systems access to volatile variables actually can cause such
effects. So what you're saying is contradicted both by what the
Standard says, and by the way real systems behave.


And for that reason a conforming implementation is just obliged to
provide the one-to-one mapping for such an access. That's what the
standard "provides."

You have misunderstood what "provides" applies to.


For example, if two volatile-qualified bitfields share the same
allocation unit, it depends on an implementation whether an access to
one of them is considered to an access to the other, so a strictly
conforming program's output is not allowed to depend on it. But, if
an implementation messes up its execution after the access, which is
not allowed by "implementation-defined" in the standard, it should be
never qualified as conforming.

I take it for granted that you're not stupid, but you have
misunderstood, mistranslated, or misinterpreted the text in the
Standard that talks about this. It is only /what constitutes an
access/ that is implementation-defined; once an access occurs,
the result is not implementation-defined but undefined -- the
particular phrase is "may be modified in ways unknown to the
implementation or have other unknown side effects". The fact
that both are listed means there may be unknown side effects to
memory other than to the variable in question, otherwise it would
say just "may be modified in ways unknown to the implementation"
and not mention the part about other side effects.


On the other hand, converting an integer to a pointer value, using a
non-conforming linker that maps a special storage to a volatile
object with a specific name, or calling a function labelled non-
conforming to get a pointer value lets an implementation behave in
its own way and does its job well in connection with volatile in
practice.

There is no requirement that an implementation document or define
what happens when a volatle variable is accessed. On the
contrary, the Standard specifically uses the wording "unknown to
the implementation" and "other unknown side effects." It's clear
the Standard not only doesn't require that these be documented,
it expects that in general the implementation won't even know
what they are.


Also note that, in the committee document I cited, one of the
committee member did not include a volatile access in the list that
should be reworded as "implementation-limited" which is in fact
undefined behavior for which the standard reuiqres documentation.
Even if its author does not represent the committee, I've seen at
least three committee members said the same thing until now. This
issue is on my PDR list that I can't complete yet due to the lack of
free time, but I'm pretty sure how the wording in question would be
revised.

Irrelevant, since it doesn't affect either what I've said
about undefined behavior or what I've said about programs
using volatile variables not being strictly conforming,
as I have already explained.


[...]
I take the example as to show that the only thing the standard
requires for "volatile" is the one-to-one mapping and the freedom of
an implementation detail on the volatile access is restricted to that
extent.

You have cause and effect reversed.

Depends on a viewpoint; it can be seen as an example to show what the
standard allows and requires for a volatile-access. However, I don't
think it is quite meaningful to discuss the example for this issue.

Since you don't think it's meaningful, can we proceed as though
you never brought it up?
.

Relevant Pages

  • Re: Volatile in C99
    ... The difference is that importance of volatile in the ... not solely by the text of the standard. ... with the wording in question, since it would be revised to reflect ... unknown side-effects may be. ...
    (comp.std.c)
  • Re: Volatile in C99
    ... The difference is that importance of volatile in the ... not solely by the text of the standard. ... with the wording in question, since it would be revised to reflect ... unknown side-effects may be. ...
    (comp.std.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)
  • Re: Volatile in C99
    ... written so as not to need volatile for such cases. ... but saying setjmpcan be used in a strictly conforming ... the wording should be clarified. ... it isn't clear what possibilities the Standard "provides". ...
    (comp.std.c)
  • Re: Use of volatile const
    ... There's no reasonable way for that to happen, but the standard only ... It simply says "volatile qualified". ... int main ... the last store need not be explicit in the program." ...
    (comp.std.c)