mirror/autoconf
2
0
Fork 0
mirror of git://git.sv.gnu.org/autoconf synced 2025-04-06 15:10:23 +08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
less skeptical about "volatile".
This commit is contained in:
Paul Eggert 2006-07-24 19:35:50 +00:00
parent 9c1ab8a186
commit 9ef3d1d118
2 changed files with 27 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
ChangeLog
View File

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

28
doc/autoconf.texi
View File

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