* doc/autoconf.texi (Volatile Objects): Be even a little

less skeptical about "volatile".

diff --git a/ChangeLog b/ChangeLog
index e9109072020131ae518c102f475726c833f6d435..4e652b7b7b960ca47b87a25cdea707f64a2a2f56 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2006-07-24  Paul Eggert  <eggert@cs.ucla.edu>
+
+       * doc/autoconf.texi (Volatile Objects): Be even a little
+       less skeptical about "volatile", after discussion with
+       Bruno Haible on bug-gnulib.
+
 2006-07-20  Paul Eggert  <eggert@cs.ucla.edu>
 
        * lib/autoconf/libs.m4 (AC_PATH_XTRA): Don't use -R if the

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index fa411588a0a72f7ca207adc4c854992937fded8f..5f7ea204530fe3da1c9f65e790e4667a930766d4 100644 (file)
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -14949,18 +14949,32 @@ restrictions imposed by the @acronym{GNU} C library.  Restrictions
 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 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.
+limits imposed by the C and Posix standards.
+
+If this is not practical, you can try the following rules of thumb.  A
+signal handler should access only volatile lvalues, preferably lvalues
+that refer to objects defined with a volatile type, and should not
+assume that the accessed objects have an internally consistent state
+if they are larger than a machine word.  Furthermore, installers
+should employ compilers and compiler options that are commonly used
+for building operating system kernels, because kernels often need more
+from @code{volatile} than the C Standard requires, and installers who
+compile an application in a similar environment can sometimes benefit
+from the extra constraints imposed by kernels on compilers.
+Admittedly we are handwaving somewhat here, as there are few
+guarantees in this area; the rules of thumb may help to fix some bugs
+but there is a good chance that they will not fix them all.
 
 For @code{volatile}, C++ has the same problems that C does.
 Multithreaded applications have even more problems with @code{volatile},
 but they are beyond the scope of this section.
 
+The bottom line is that using @code{volatile} typically hurts
+performance but should not hurt correctness.  In some cases its use
+does help correctness, but these cases are often so poorly understood
+that all too often adding @code{volatile} to a data structure merely
+alleviates some symptoms of a bug while not fixing the bug in general.
+
 @node Floating Point Portability
 @section Floating Point Portability
 @cindex floating point