Re: Volatile in C99

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

The main purpose of the non-local jump facility is to implement an
exception handling mechanism and such a purpose brings code
non-trivial use of it, which means without any way to preserve the
value of a local variable modified between setjmp and longjmp, the
facility is next to useless.

Untrue, since any code that uses setjmp/longjmp can easily be
written so as not to need volatile for such cases.

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

[...]
Unlike signal handling, the standard carefully specifies the
<setjmp.h> facility so that it does not restrict its usefulness in a
strictly conforming program.

Perhaps, but saying setjmp() can be used in a strictly conforming
way doesn't mean all possible uses of setjmp() are strictly
conforming. And it certainly doesn't mean that using volatile
must be strictly conforming, since using volatile isn't
necessary to use setjmp/longjmp in a well-defined way.


"must" be strictly conforming? Don't forget I said:

but I do not claim that such a belief can readily turn to a firm
fact solely by the text of the standard, which is the reason I said
the wording should be clarified.

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?

Okay, this isn't not a firm evidence to show using "volatile" *must*
be s.c., but implies that the wording saying an opposite thing cannot
be taken as much that easily.

[...]

unless it depends on the details
of a volatile access by invoking a non-portable way to do so

I don't know what this part of the sentence is supposed to mean.


You don't need to do until we start to discuss how the wording for
"volatile" should be fixed.

[...]

Furthermore, any hope that volatile can be used in a strictly
conforming program is pretty minimal, because of the statement
that what constitutes an access to a volatile object is
implementation-defined, and there are no clear boundaries on
how much latitude implementations have in such definitions.


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.

We are opening another can of worms. The conformance categories
specified by the standard is incomplete, as admitted by the
committee. For example, the standard specifies an implementation
can behave in a non-conforming way if code contains (non-standard)
#pragma's, by saying the directive causes an implementation to
behave in an "implementation-defined" way. I think the intent here is
to specify an "undefined" behavior for which the committee requires
an implementation to document. So the wording "implementation-
defined" is hired there just for asking for its documentation, not
for allowing other i-d things to make a program result in undefned
behavior. The wording to say "non-conforming manner" is there for an
"implementation-defined" characteristic itself never invalidates code
relying on it. See 7.20.4.6 (system) for the similar case.

which is implied by an example for the standard's program execution
model:

[copied from C90] An implementation might define a one-to-one
correspondence between abstract and actual semantics: at every
sequence point, the values of the actual objects would agree with
those specified by the abstract semantics. The keyword volatile
would then be redundant.

What this text means is that, on that implementation, volatile
could be omitted without provoking the undefined behavior clauses
related to omitting volatile, because the implementation actually
defines the behavior in such cases. It doesn't say anything about
what using volatile means in implementations generally.


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.

but I do not claim that such a belief can readily turn to a firm fact
solely by the text of the standard, which is the reason I said the
wording should be clarified.

I absolutely agree the wording in the Standard should be
improved and clarified.

You asserted the opposite position sticking to a poorly-worded
sentence (it's poorly-worded at least since it can be taken as saying
a different thing from what the other parts of the standard say),
which is too hasty.

I don't like having to rely on poorly worded sentences in the
Standard, but in this case the sentences I've mentioned are the
only ones I've been able to find that clearly have a bearing on
the subject.


Not that clearly. The only wording you're counting on is written too
vaguely to determine the latitude of a volatile access, which is why
we say a wording fix is in order.

As for the poorly worded sentences saying something different
from other parts of the Standard - in future postings please
be specific in quoting which parts those might be. So far
the only portion you've quoted is the example implementation
described in 5.1.2.3 p 8. If you need access to a copy of
the Standard, there is this URL:

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf


I had a troble in reading my copy of the final standard since my pdf
reader, not the copy, didn't work correctly, but thanks anyway.


--
Jun, Woong (woong at icu.ac.kr)
.

Relevant Pages

  • 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: 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
    ... Yes as it is your opinion not everyone's that an access to volatile ... The standard is a means for the committee to express their intent. ... with the wording in question, since it would be revised to reflect ... allowed to let a conforming implementation to behave in a non- ...
    (comp.std.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)
Loading