Make it clear that 'timeout' interval will be rounded up to the
system clock granularity, and may overrun because of kernel
scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it clear that 'timeout' interval will be rounded up to the
system clock granularity, and may overrun because of kernel
scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it clear that 'timeout' is a minimum interval; the actual
interval will be rounded up to the system clock granularity,
and may overrun because of kernel scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it clear that 'timeout' is a minimum interval; the actual
interval will be rounded up to the system clock granularity,
and may overrun because of kernel scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it clear that 'timeout' is a minimum interval; the actual
interval will be rounded up to the system clock granularity,
and may overrun because of kernel scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it clear that 'timeout' is a minimum interval; the actual
interval will be rounded up to the system clock granularity,
and may overrun because of kernel scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It must be a very long time since the statement there
about SIGLOST was true. (The text seems to date back to
1996.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it clear that this clock may be discontinuous, and is
affected my incremental NTP and clock-adjtime(2) adjustments.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540872
Reported-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This patch clarifies that 0xc0 and 0xc1 are not valid in any UTF-8
encoding[0], and it also references RFC 3629 instead of RFC 2279.
[0] In order to have 0xc0, you'd have to have a two-byte encoding
with all the data bits zero in the first byte (and thus only six
bits of data), which would be an ASCII character encoded in the
non-shortest form. Similarly with 0xc1.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538641
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The example code was a version that was not consistent with
the shell output shown on the page.
Reported-bY: Simon Paillard <spaillard@debian.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
fopen() permits, for example, both "w+b" and "wb+",
but only the latter is meaningful to fmemopen().
See http://sourceware.org/bugzilla/show_bug.cgi?id=12836
Reported-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
If 'mode' is append, but 'size' does not cover a null byte
in 'buf', then fmemopen() incorrectly sets the initial file
position to -1, rather than the next byte after the end of
the buffer.
See http://sourceware.org/bugzilla/show_bug.cgi?id=13151
Reported-by: Rich Felker <bugdal@aerifal.cx>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Append mode correctly sets the initial offset but does
not force subsequent writes to append at end of stream.
See http://sourceware.org/bugzilla/show_bug.cgi?id=13152
Reported-by: Rich Felker <bugdal@aerifal.cx>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
If size is zero, fmemopen() fails, This is surprising behavior,
and not specified in POSIX.1-2008.
See http://sourceware.org/bugzilla/show_bug.cgi?id=11216
Reported-by; Alex Shinn <alexshinn@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Ivana Varekova