From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 29 Oct 2024 20:37:19 +0000 (-0700)
Subject: Update ‘volatile’ doc for C23
X-Git-Url: http://git.ipfire.org/gitweb/gitweb.cgi?a=commitdiff_plain;h=dc328e3978dbaa39dda47d51829086c2703b2cde;p=thirdparty%2Fautoconf.git

Update ‘volatile’ doc for C23

* doc/autoconf.texi (Volatile Objects): Update for C23.
---

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index b9fbbc61..1ff2f47d 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -21782,8 +21782,10 @@ 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:
+files.  However, accesses via volatile lvalues to ordinary objects
+are merely side effects (i.e., changes to the state of the execution
+environment), and the implementation is not required to document
+their visibility any further.  For example:
 
 @example
 /* Declare and access a volatile object.
@@ -21792,14 +21794,16 @@ static int volatile x;
 x = 1;
 
 /* Access two ordinary objects via a volatile lvalue.
-   It's not clear whether accesses to *P are "visible".  */
-int y;
-int *z = malloc (sizeof (int));
+   Although each read and write is a side effect,
+   the accesses are not directly "visible" to users.  */
+int y = 0;
+int *z = malloc (sizeof *z);
+*z = 7;
 int volatile *p;
 p = &y;
-*p = 1;
+*p = *p + 1;
 p = z;
-*p = 1;
+*p = *p + 1;
 @end example
 
 Programmers often wish that @code{volatile} meant ``Perform the memory
@@ -21807,32 +21811,19 @@ 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 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.
+otherwise merging, reordering, and word-size change is allowed.
 
 Even when accessing objects defined with a volatile type,
 the C standard allows only
-extremely limited signal handlers: in C99 the behavior is undefined if a signal
-handler reads any non-local object, or writes to any non-local object
-whose type is not @code{sig_atomic_t volatile}, or calls any standard
-library function other than @code{abort}, @code{signal}, and
-@code{_Exit}.  Hence C compilers need not worry about a signal handler
-disturbing ordinary computation.  C11 and POSIX allow some additional
-behavior in a portable signal handler, but are still quite restrictive.
-
-Some C implementations allow memory-access optimizations within each
-translation unit, such that actual behavior agrees with the behavior
-required by the standard only when calling a function in some other
-translation unit, and a signal handler acts like it was called from a
-different translation unit.  The C99 standard hints that in these
-implementations, objects referred to by signal handlers ``would require
-explicit specification of @code{volatile} storage, as well as other
-implementation-defined restrictions.''  But unfortunately even for this
-special case these other restrictions are often not documented well.
-This area was significantly changed in C11, and eventually implementations
-will probably head in the C11 direction, but this will take some time.
+extremely limited signal handlers: in C23 the behavior is undefined if a
+signal handler refers to any non-local object that is not a lock-free
+atomic object and that is not @code{constexpr} (other than by writing to
+a @code{sig_atomic_t volatile} object), or calls any standard library
+function other than from a small set that includes @code{abort},
+@code{_Exit}, @code{quick_exit}, some @code{<stdatomic.h>} functions,
+and @code{signal}.  Hence C compilers need not worry about a signal
+handler disturbing ordinary computation.  POSIX allows some additional
+behavior in a portable signal handler, but is still quite restrictive.
 @xref{Volatiles, , When is a Volatile Object Accessed?, gcc, Using the
 GNU Compiler Collection (GCC)}, for some
 restrictions imposed by GCC.  @xref{Defining Handlers, ,