Re: new module for temporary files in temporary directories

[Paul Eggert]

Ben Pfaff <address@hidden> writes:

> Is this a feature that Bruno will add later?

I suspect so, if we want 'sort' to use the module (still haven't
decided that).

> My theory is that any object may be accessed through a volatile
> lvalue and receive volatile semantics *for that access*.... That
> doesn't make the object volatile

OK, though in your earlier email you've used "volatile object" to talk
about any object accessed via a volatile lvalue -- unless I
misunderstood that.

I think your theory is self-consistent, but the standard would have to
be worded somewhat differently for this interpretation to be required
by the standard.  For example, 5.1.2.3.(5) is hopelessly muddled under
your interpretation:

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

because this is supposed to be talking about lvalues, not objects.  It
should be reworded to be something like this:

   At sequence points, previous accesses via volatile lvalues are
   complete and subsequent accesses via volatile lvalues have not yet
   occurred.

And we'd have to add something like this somewhere:

   If an object is accessed by both volatile and nonvolatile lvalues,
   the behavior is implementation-defined.

It also strikes me that the standard nowhere defines the term
"volatile object".  If this term means "object with a volatile type"
then the lvalue-access theory would make sense (though some rewording
would be required, as suggested above); if it means "object defined
with a volatile type" then the more-conservative theory would be more
appropriate.

> (rationale 6.7.3, last paragraph)

I read the rationale, and that paragraph is indeed suggestive, but
there are some problems nearby that make me dubious.  For example,
6.7.3 line 20 says that for a volatile lvalue "the location is not
guaranteed to contain any previous value", which indicates that
they're thinking about memory-mapped registers, not about access to
ordinary memory.

Almost all the "volatile" examples in the rationale talk about
memory-mapped registers and the like.  There is one exceptional
sentence, "A volatile object is also an appropriate model for a
variable shared among multiple processes", but as we've seen from
cpp-threads, this sentence is merely an expression of hope and turns
out to be dead wrong.

Also, 5.2.3 line 8 incorrectly says that portable signal handlers can
call longjmp; this was true in C89 but not C99, which leads me to
think that the rationale was hastily updated for C99 in the
signal/volatile area, and may not reflect the committee's 1999
thinking.

Anyway, thanks for the discussion, and I have updated the Autoconf
documentation to include this slightly less pessimistic version.

2006-07-07  Paul Eggert  <address@hidden>

        * doc/autoconf.texi (C Compiler): Add a ref to Volatile Objects
        under AC_C_VOLATILE.
        (Volatile Objects): Be a little less skeptical about what
        "volatile" means.  Derived from thoughts by Ben Pfaff in
        <http://lists.gnu.org/archive/html/bug-gnulib/2006-07/msg00092.html>.

--- autoconf.texi       7 Jul 2006 18:39:38 -0000       1.1059
+++ autoconf.texi       7 Jul 2006 18:43:49 -0000       1.1060
@@ -6507,6 +6507,7 @@ If the correctness of your program depen
 your code.  However, given that the compiler does not support
 @code{volatile}, you are at its mercy anyway.  At least your
 program compiles, when it wouldn't before.
address@hidden Objects}, for more about @code{volatile}.
 
 In general, the @code{volatile} keyword is a standard C feature, so
 you might expect that @code{volatile} is available only when
@@ -14846,24 +14847,33 @@ The keyword @code{volatile} is often mis
 Its use inhibits some memory-access optimizations, but programmers often
 wish that it had a different meaning than it actually does.
 
-One area of confusion is the distinction between volatile objects and
-volatile lvalues.  From the C standard's point of view, a volatile
-object 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; only volatile objects can be observed by the user.
-Hence in general it does not help to use pointer-to-volatile to control
-access to ordinary objects.  For example:
address@hidden was designed for code that accesses special objects like
+memory-mapped device registers whose contents spontaneously change.
+Such code is inherently low-level, and it is difficult to specify
+portably what @code{volatile} means in these cases.  The C standard
+says, ``What constitutes an access to an object that has
+volatile-qualified type is implementation-defined,'' so in theory each
+implementation is supposed to fill in the gap by documenting what
address@hidden means for that implementation.  In practice, though,
+this documentation is usually absent or incomplete.
+
+One area of confusion is the distinction between objects defined with
+volatile types, and volatile lvalues.  From the C standard's point of
+view, an object defined with a volatile type has externally visible
+behavior.  You can think of such objects as having little oscilloscope
+probes attached to them, so that the user can observe some properties of
+accesses to them, just as the user can observe data written to output
+files.  However, the standard does not make it clear whether users can
+observe accesses by volatile lvalues to ordinary objects.  For example:
 
 @example
 /* Declare and access a volatile object.
-   'volatile' has a well-defined effect here.  */
+   Accesses to X are "visible" to users.  */
 static int volatile x;
 x = 1;
 
 /* Access two ordinary objects via a volatile lvalue.
-   It's not clear what 'volatile' means here.  */
+   It's not clear whether accesses to *P are "visible".  */
 int y;
 int *z = malloc (sizeof (int));
 int volatile *p;
@@ -14875,21 +14885,26 @@ p = z;
 
 Programmers often wish that @code{volatile} meant ``Perform the memory
 access here and now, without merging several memory accesses, without
-changing the memory word size, and without reordering.''  But the
-C standard does not require this.  For volatile @emph{objects}, accesses
-must be done before the next sequence point; but otherwise merging,
-reordering, and word-size change is allowed.  Worse, volatile
address@hidden provide no more guarantees in general than nonvolatile
-lvalues, when the underlying objects are nonvolatile.
+changing the memory word size, and without reordering.''  But the C
+standard does not require this.  For objects defined with a volatile
+type, accesses must be done before the next sequence point; but
+otherwise merging, reordering, and word-size change is allowed.  Worse,
+it is not clear from the standard whether volatile lvalues provide more
+guarantees in general than nonvolatile lvalues, if the underlying
+objects are ordinary.
 
-Even when accessing volatile objects, the C standard allows only
+Even when accessing objects defined with a volatile type,
+the C standard allows only
 extremely limited signal handlers: the behavior is undefined if a signal
 handler reads any nonlocal object, or writes to any nonlocal object
 whose type is not @code{sig_atomic_t volatile}, or calls any standard
 library function other than @code{abort}, @code{signal}, and (if C99)
address@hidden  Hence C compilers do not need to worry about a signal
address@hidden  Hence C compilers need not worry about a signal handler
 disturbing ordinary computation, unless the computation accesses a
address@hidden volatile} object that is not a local variable.  Posix
address@hidden volatile} lvalue that is not a local variable.
+(There is an obscure exception for accesses via a pointer to a volatile
+character, since it may point into part of a @code{sig_atomic_t
+volatile} object.)  Posix
 adds to the list of library functions callable from a portable signal
 handler, but otherwise is like the C standard in this area.
 
@@ -14911,9 +14926,10 @@ differ on other platforms.
 
 If possible, it is best to use a signal handler that fits within the
 limits imposed by the C and Posix standards.  If this is not practical,
-then a signal handler should access only volatile objects, and should
-not assume that volatile objects larger than a machine word have an
-internally consistent state.  If that is not practical either, then it
+then a signal handler should access only objects defined with a volatile
+type, and should not assume that these objects have an internally
+consistent state if they are larger than a machine word.  If that is not
+practical either, then it
 may be difficult to write portable code, and it is not clear whether
 using volatile lvalues will help much.
 
@@ -18967,7 +18983,7 @@ introduced in this document.
 @c  LocalWords:  mkdir exe uname OpenBSD Fileutils mktemp umask TMPDIR guid os
 @c  LocalWords:  fooXXXXXX Unicos parenthesization utimes hpux hppa unescaped
 @c  LocalWords:  pmake DOS's gmake ifoo DESTDIR autoconfiscated pc coff mips gg
address@hidden  LocalWords:  dec ultrix cpu wildcards rpcc rdtsc powerpc 
behaviour readline
address@hidden  LocalWords:  dec ultrix cpu wildcards rpcc rdtsc powerpc 
readline
 @c  LocalWords:  withval vxworks gless localcache usr LOFF loff CYGWIN Cygwin
 @c  LocalWords:  cygwin SIGLIST siglist SYSNDIR SYSDIR ptx lseq rusage elif MSC
 @c  LocalWords:  lfoo POUNDBANG lsun NIS getpwnam SYSCALLS RSH INTL lintl aix