Note the use of open_memstream() to store XML output
directly into a buffer.
Reported-by: Jakub Jelinek <jakub@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A change in 2.6.28 restored the 2.2 behavior:
https://lkml.org/lkml/2009/6/30/499
Reported-by: lepton <ytht.net@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Note interactions of these two clocks with discontinuous
adjustments to the system time and NTP/adjtime(2).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add some basic documentation of these operations, with a pointer to
tools/perf/design.txt for more information.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
SPARC reverses the use of 'addr' and 'data' for
PTRACE_GETREGS, PTRACE_GETFPREGS, PTRACE_SETREGS,
and PTRACE_SETFPREGS.
Reported-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
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>
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>
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>
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:
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_10.html
Reported-by: Alexey Toptygin <alexeyt@freeshell.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The value is not meant to be a maximum (as was specified in
SUSv3) but an initial guess at the required size
(as specified in SUSv4).
Reported-by: Ulrich Drepper <drepper@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The value is not meant to be a maximum (as was specified in
SUSv3) but an initial guess at the required size
(as specified in SUSv4).
Reported-by: Ulrich Drepper <drepper@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>