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