The POSIX situation has been the norm for a long time now,
and including ancient details overcomplicates the page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The discussion about pre-POSIX types for 'timeval' and 'timespec'
is rather old, and these days serves mainly to complicate the
page. Remove it.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The current text layout is a little hard to parse, with details of
pselect() spread in the main description. Move some of that text
to a headed subsection, and add a one-sentence introduction
describing the purpose of pselect().
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
One might be tempted to think that realloc() always requests a new
allocation before moving the contents over (at least in the case
where the new size is bigger than the original). This is not the
case; for example, on my system the following program:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
void *x = malloc(15);
void *y = malloc(32);
printf("x = %p\n", x);
printf("y = %p\n", y);
printf("usable_size(x) = %lu\n", malloc_usable_size(x));
void *z = realloc(x, 24);
printf("z = %p\n", z);
return 0;
}
prints:
x = 0x1b3a010
y = 0x1b3a030
usable_size(x) = 24
z = 0x1b3a010
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Admittedly, the POSIX specification for exit() also uses octal.
However, 0xFF immediately indicates the lowest 8 bits to me
whereas I had to think a bit about the octal mask.
Cowritten-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This was already shown in an earlier version of the page,
but Adam Borowski's patch replaced it with an alternative.
Probably, it is better to show both possibilities.
Reported-by: "Joseph C. Sible" <josephcsible@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In the example snippet, we already have the fd, thus there's no
need to refer to the file by name. And, /proc/ might be not
mounted or not accessible.
Noticed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Supported since fadb4244085cd04fd9c8b3a4b3bc161f506431f3 (4.9),
100..107 are supposed to be bright but this does not yet work
(unmerged patches to do so exist).
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Supported since cec5b2a97a11ade56a701e83044d0a2a984c67b4 (3.16).
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since 65d9982d7e523a1a8e7c9af012da0d166f72fc56 (4.17), it follows
xterm rather than common sense and consistency, being the only
command 1..9 where N+20 doesn't undo what N did. As libvte
0.51.90 got changed the same way, this behaviour will probably
stay.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From an email by Rich Felker:
It came to my attention while reviewing possible breakage with
move to 64-bit time_t that some applications are dereferencing
data in socket control messages (particularly SCM_TIMESTAMP*)
in-place as the message type, rather than memcpy'ing it to
appropriate storage. This necessarily does not work and is not
supportable if the message contains data with greater alignment
requirement than the header. In particular, on 32-bit archs,
cmsghdr has size 12 and alignment 4, but struct timeval and
timespec may have alignment requirement 8.
I found at least ptpd, socat, and ssmping doing this via Debian
Code Search:
https://sources.debian.org/src/ptpd/2.3.1-debian1-4/src/dep/net.c/?hl=1578#L1578https://sources.debian.org/src/socat/1.7.3.3-2/xio-socket.c/?hl=1839#L1839https://sources.debian.org/src/ssmping/0.9.1-3/ssmpngcl.c/?hl=307#L307
and I suspect there are a good deal more out there. On most archs
they won't break, or will visibly break with SIGBUS, but in theory
it's possible that they silently read wrong data and this might
happen on some older and more tiny-embedded-oriented archs.
I think it's clear to someone who understands alignment and who's
thought about it that applications just can't do this, but it
doesn't seem to be documented, and an example in cmsg(3) even
shows access to int payload via *(int *)CMSG_DATA(cmsg) (of course
int is safe because its alignment is <= header alignment, but this
is not mentioned).
Could we add text, and perhaps change the example, to indicate
that in general memcpy needs to be used to copy the payload
to/from a suitable object?
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
PTRACE_EVENT_STOP does not always report SIGTRAP, can be the
signal which stopped us
While at it, fix an obvious copy/paste error in
PTRACE_GET_SYSCALL_INFO description.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>