mirror/autoconf
2
0
Fork 0
mirror of git://git.sv.gnu.org/autoconf synced 2024-11-27 01:49:56 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update ‘volatile’ doc for C23

Browse Source 
* doc/autoconf.texi (Volatile Objects): Update for C23.
This commit is contained in:
Paul Eggert 2024-10-29 13:37:19 -07:00
parent 30ee10e273
commit dc328e3978
1 changed files with 21 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
doc/autoconf.texi
View File

@ -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, ,