This is the mail archive of the libc-hacker@sourceware.org mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Manual] memory access atomicity

Hi, 

I found a bug in the description of sig_atomic_t.  It said:

	In practice, you can assume that @code{int} and other integer
	types no longer than @code{int} are atomic.

This is untrue, for example, 16-bit access or 8-bit access on Alpha is
not atomic.

Here is a patch to point out this issue.

Index: signal.texi
===================================================================
RCS file: /cvs/glibc/libc/manual/signal.texi,v
retrieving revision 1.70
diff -u -3 -p -r1.70 signal.texi
--- signal.texi	12 Jul 2004 21:44:33 -0000	1.70
+++ signal.texi	2 Sep 2005 06:37:07 -0000
@@ -2029,8 +2029,8 @@ This is an integer data type.  Objects o
 atomically.
 @end deftp
 
-In practice, you can assume that @code{int} and other integer types no
-longer than @code{int} are atomic.  You can also assume that pointer
+In practice, you can assume that @code{int} is atomic.
+You can also assume that pointer
 types are atomic; that is very convenient.  Both of these assumptions
 are true on all of the machines that the GNU C library supports and on
 all POSIX systems we know of.
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]