Michael Kerrisk [Mon, 23 Apr 2012 20:56:35 +0000 (08:56 +1200)]
memchr.3: Clarify description, omitting mention of "strings" and "characters"
The existing text slipped into talking about characters and
strings, which could mislead readers into thing that, for
example, searches for the byte '\0' are treated specially.
Therefore, rewrite in terms of "bytes" and "memory areas".
At the same time, make a few source file clean-ups.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
James Hunt [Mon, 23 Apr 2012 20:39:33 +0000 (08:39 +1200)]
strchr.3: Explain behavior when seraching for '\0'
The strchr(3) page does `not explain the behavior if the
character to search for is specified as a null character ('\0').
According to my copy of Harbison and Steele, since the terminator
is considered part of the string, a call such as:
strchr("hello", '\0')
will return the address of the terminating null in the specified
string.
strchr(3) is inconsistent with index(3) which states:
"The terminating null byte is considered to be
a part of the strings."
Adding such a note to strchr(3) is also important since it is not
unreasonable to assume that strchr() will return NULL in this
scenario. This leads to code like the following which is
guaranteed to fail should get_a_char() return '\0':
char string[] = "hello, world";
int c = get_a_char();
if (! strchr(string, c))
fprintf(stderr, "failed to find character in string\n");
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Mon, 23 Apr 2012 09:30:59 +0000 (21:30 +1200)]
prctl.2: Amend details of PR_SET_PDEATHSIG
The corresponding kernel change from Marchel Holtmann was
The attached patch fixes a flaw in the "parent process
death signal" when executing SUID binaries. An
unprivileged user may send arbitrary signal to a child
process even if it is running with higher privileges.
The idea to fix this issue is to reset pdeath_signal not
only on fork, but also on the execution of a SUID binary.
Reported-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
tcp.7: Correct description for TCP_MAXSEG on modern kernel
In tcp.7, about TCP_MAXSEG, it reads
If this option is set before connection establishment,
it also changes the MSS value announced to the other
end in the initial packet.
It is correct for kernel version 2.2, but it is not
correct for modern kernel such as 2.4 and 2.6.
On a linux box with a modern kernel, the setting for
TCP_MAXSEG won't change the MSS value announced to the
other end.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Mon, 23 Apr 2012 09:02:31 +0000 (21:02 +1200)]
socket.7: Correct description of SO_BROADCAST
As reported by Alexey:
socket(7) says:
SO_BROADCAST
Set or get the broadcast flag. When enabled, datagram sockets
receive packets sent to a broadcast address and they are allowed
to send packets to a broadcast address. This option has no
effect on stream-oriented sockets.
I believe the second sentence is half wrong: when I try it, it
only affects the ability to send broadcast datagrams. You can only
receive broadcast datagrams if you bind to INADDR_ANY and don't
connect. The POSIX standard agrees with my tests and disagrees
with the manpage:
netdevice.7: Document some SIOC configuration ioctls
This patch adds common but missing SIOC configuration ioctls to
the netdevice.7 manual pages that are not documented anywhere
else. SIOCSIFPFLAGS and SIOCGIFPFLAGS are linux-specific. Flag
values come from Linux 2.6.25 kernel headers for sockios. The
others are standard BSD ioctls that have alwasy been implemented
by Linux and were verified from inspecting netdevice.c kernel
code.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Stefan Puiu [Sun, 22 Apr 2012 20:15:01 +0000 (08:15 +1200)]
send.2: Document EACCES error case for UDP
It seems sendto() can return EACCES for UDP as well; the current
man page in git only says it can return EACCES for Unix sockets.
I was able to make sendto() return EACCES if I try to send from
192.168.1.1/24 to 192.168.1.0. I think the relevant code (in
kernel 2.6.38, but also present in 2.6.7 and 2.6.32, the 2 kernels
we use) is this (net/ipv4/udp.c, udp_sendmsg()):
So I guess if the kernel finds a route to the destination and
it's a broadcast route (and the socket doesn't have the broadcast
flag), then it returns EACCES.
I can verify the behavior with a very simple program (attached).
I've run it on my Ubuntu 10.10 (2.6.35 kernel) and got this:
stefan@spuiu-vml2:~/src/test/broadcast$ ./broadcast_test 10.205.20.94
10.205.20.1
sendto() returned 4
stefan@spuiu-vml2:~/src/test/broadcast$ ./broadcast_test 10.205.20.94
10.205.20.0
sendto() returned negative, errno: 13/Permission denied
Eric Blake [Sun, 22 Apr 2012 00:13:31 +0000 (12:13 +1200)]
strerror.3: Improve strerror_r() description
POSIX requires that perror() not modify the static storage
returned by strerror(). POSIX 2008 and C99 both require that
strerror() never return NULL (a strerror() that always
returns "" for all inputs is valid for C99, but not for POSIX).
http://sourceware.org/bugzilla/show_bug.cgi?id=12204
documents glibc's change to come into compliance with POSIX
regarding strerror_r() return value. The GNU strerror_r() use
of 'buf' was confusing - I ended up writing a test program that
proves that 'buf' is unused for valid 'errnum', but contains
truncated "unknown message" for out-of-range 'errnum'.
See also http://austingroupbugs.net/view.php?id=382
Reviewed-by: Stefan Puiu <stefan.puiu@gmail.com> Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Bernhard Walle [Sat, 21 Apr 2012 23:09:37 +0000 (11:09 +1200)]
strerror.3: Correct description of error return for XSI strerror_r()
The XSI-compliant version of strerror_r() doesn't return -1 on
error and set errno. Instead, a positive error number is returned.
That's what POSIX says:
Upon successful completion, strerror_r() shall return 0.
Otherwise, an error number shall be returned to indicate
the error.
I tested with an invalid error number. While some implementations
seem to write "Unknown error xxx" into the supplied buffer, some
others don't and only return EINVAL. The latest glibc 2.14.1 from
Arch Linux belongs to the first category while eglibc 2.13 from
current Debian testing belongs to the second category.
However, both implementation are correct according to POSIX. So I
think the manpage was wrong and POSIX and the implementations are
correct.
Signed-off-by: Signed-off-by: Bernhard Walle <bernhard@bwalle.de> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Fri, 20 Apr 2012 03:53:32 +0000 (15:53 +1200)]
posix_openpt.3: Add some details on use of the slave pathname
An explicit pointer to ptsname(3) is useful, as is a note
of the fact that the slave device pathname exists only as
long as the master device is held open.
Reported-by: Vadim Mikhailov <vadim.mikhailov@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Fri, 20 Apr 2012 01:14:31 +0000 (13:14 +1200)]
sigaction.2: Remove mention of raise(3) for SI_USER
For a long time now, glibc's raise(3) didn't yield SI_USER
for the signal receiver, so remove mention of raise(3)
here. The user can deduce the details, if needed, by looking
at the recently updated raise(3) page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
projects / thirdparty / man-pages.git / log
