Re: new module for temporary files in temporary directories

[Ben Pfaff]

Paul Eggert <address@hidden> writes:

> Bruno Haible <address@hidden> writes:
>
>> 3) The theoretical reason is that in ISO C, section 5.1.2.3.(5)
>> guarantees to me that memory stores have been performed at sequence points
>> only if I mark them 'volatile'.
>
> I think that's a misunderstanding of that section.
>
> From the C standard's point of view, a volatile object (not merely an
> object accessed via a volatile lvalue, but a volatile object, e.g.,
> "static int volatile x;") has externally visible behavior.  You can
> think of such objects as having little oscilloscope probes attached to
> them, so that the user can observe every access to them, just as the
> user can observe data written to output files.  This is not true of
> ordinary objects accessed via volatile lvalues (which is what the new
> module mostly uses); only volatile objects can be observed by the
> user.
>
> 5.1.2.3.(5) talks only about volatile objects; it does not place any
> constraints on accesses to ordinary objects via volatile lvalues.

This is a particularly pessimistic interpretation of the
standard, and I do not agree with it.  The standard is careful to
distinguish between objects of a type and objects *defined* with
a particular type.  An object having a type is just ascribing a
relatively arbitrary type to a memory region, as you can see from
the relevant definitions in C99:

     3.14
1    object
     region of data storage in the execution environment, the
     contents of which can represent values
2    NOTE When referenced, an object may be interpreted as having a
     particular type; see 6.3.2.1.

...

     6.3.2 Other operands
     6.3.2.1  Lvalues, arrays, and function designators
1    An lvalue is an expression with an object type or an incomplete
     type other than void;53) if an lvalue does not designate an
     object when it is evaluated, the behavior is undefined.
     When an object is said to have a particular type, the type
     is specified by the lvalue used to designate the object.

Note in particular the final sentence above: the type used for an
object is a function of the lvalue.

An object *defined* as a type means that there is a declaration
that says it has the type, as in your "static int volatile x;"
example.

The standard carefully distinguishes these forms of reference.
For example, 6.7.3p5 talks about the *defined* type of an object:

     If an attempt is made to refer to an object defined with a
                                       ^^^^^^^^^^^^^^^^^^^^^^^^
     volatile-qualified type through use of an lvalue with
     ^^^^^^^^^^^^^^^^^^^^^^^
     non-volatile-qualified type, the behavior is undefined.113)

But 5.1.2.3p5 talks about the type of an object, with no
reference to how the object was defined:

     The least requirements on a conforming implementation are:

     - At sequence points, volatile objects are stable in the
                           ^^^^^^^^^^^^^^^^
       sense that previous accesses are complete and subsequent
       accesses have not yet occurred.

The C99 rationale makes this clear, in 6.7.3p10, although the
wording is looser (I do not think that the rationale receives the
same level of review as the standard itself):

      If it is necessary to access a non-volatile object using
      volatile semantics, the technique is to cast the address of
      the object to the appropriate pointer-to-qualified type,
      then dereference that pointer.
-- 
Ben Pfaff 
email: address@hidden
web: http://benpfaff.org