view doc/posix-functions/vprintf.texi @ 15326:52719068f9c2

pipe, pipe2: don't corrupt fd on error I noticed a potential subtle double-close bug in libvirt. There, a common idiom is to initialize an int fd[2]={-1,-1}, then have multiple error paths goto common cleanup code. In the cleanup code, the fds are closed if they are not already -1; this works if the error label is reached before the pipe call, or after pipe succeeds, but if it was the pipe call itself that jumped to the error label, then it is relying on failed pipe() not altering the values already in fd array prior to the failure. Our pipe2 replacement violated this assumption, and could leave a non-negative value in the array, which in turn would let libvirt close an already-closed fd, possibly nuking an unrelated fd opened by another thread that happened to get the same value. As a result, I raised a POSIX issue regarding the behavior of pipe on failure: http://austingroupbugs.net/view.php?id=467 Using that test program, I learned that most systems leave fd unchanged on error, but that mingw always assigns -1 into the array. This fixes the mingw pipe() replacement, as well as the gnulib pipe2() replacement. I don't know of any race-free way to work around a cygwin crash: http://cygwin.com/ml/cygwin/2011-06/msg00328.html - we could always open() and then close() two fds to guess whether two spare fd still remain before calling pipe(), but that is racy. * lib/pipe.c (pipe): Leave fd unchanged on error. * lib/pipe2.c (pipe2): Likewise. * doc/posix-functions/pipe.texi (pipe): Document cygwin issue. * doc/glibc-functions/pipe2.texi (pipe2): Likewise. Signed-off-by: Eric Blake <eblake@redhat.com>
author Eric Blake <eblake@redhat.com>
date Wed, 29 Jun 2011 15:46:50 -0600
parents fa0d7f167907
children 2171e9d2231b
line wrap: on
line source

@node vprintf
@section @code{vprintf}
@findex vprintf

POSIX specification:@* @url{http://www.opengroup.org/onlinepubs/9699919799/functions/vprintf.html}

Gnulib module: vprintf-posix or stdio, nonblocking, sigpipe

Portability problems fixed by Gnulib module @code{vprintf-posix}:
@itemize
@item
This function does not support size specifiers as in C99 (@code{hh}, @code{ll},
@code{j}, @code{t}, @code{z}) on some platforms:
AIX 5.1, HP-UX 11.23, IRIX 6.5, OSF/1 5.1, Solaris 9, Cygwin 1.5.24, mingw, BeOS.
@item
printf of @samp{long double} numbers is unsupported on some platforms:
mingw, BeOS.
@item
printf @code{"%f"}, @code{"%e"}, @code{"%g"} of Infinity and NaN yields an
incorrect result on some platforms:
AIX 5.2, OSF/1 5.1, Solaris 11 2010-11, mingw.
@item
This function does not support the @samp{a} and @samp{A} directives on some
platforms:
glibc-2.3.6, MacOS X 10.5, NetBSD 5.0, OpenBSD 4.0, AIX 5.2, HP-UX 11,
IRIX 6.5, OSF/1 5.1, Solaris 11 2010-11, Cygwin 1.5.x, mingw, BeOS.
@item
This function does not support the @samp{F} directive on some platforms:
NetBSD 3.0, AIX 5.1, HP-UX 11.23, IRIX 6.5, OSF/1 5.1, Solaris 9,
Cygwin 1.5.x, mingw, BeOS.
@item
This function does not support the @samp{ls} directive on some platforms:
OpenBSD 4.0, IRIX 6.5, Solaris 2.6, Cygwin 1.5.x, Haiku.
@item
This function does not support precisions in the @samp{ls} directive correctly
on some platforms:
Solaris 11 2010-11.
@item
This function does not support format directives that access arguments in an
arbitrary order, such as @code{"%2$s"}, on some platforms:
NetBSD 3.0, mingw, BeOS.
@item
This function doesn't support the @code{'} flag on some platforms:
NetBSD 3.0, Cygwin 1.5.24, mingw.
@item
This function behaves incorrectly when a @samp{-} flag and a negative width
are specified together, on some platforms:
HP-UX 10.20.
@item
printf @code{"%010f"} of NaN and Infinity yields an incorrect result (padded
with zeroes) on some platforms:
MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, AIX 5.2, IRIX 6.5, OSF/1 5.1, Solaris 11 2010-11, Cygwin 1.5.x, mingw.
@item
This function does not support precisions larger than 512 or 1024 in integer,
floating-point and pointer output on some platforms:
AIX 7.1, Solaris 10/x86, mingw, BeOS.
@item
This function mishandles large floating point precisions
(for example, formatting 1.0 with @samp{"%.511f"})
on some platforms:
Solaris 10.
@item
This function can crash in out-of-memory conditions on some platforms:
MacOS X 10.3, FreeBSD 6.0, NetBSD 5.0.
@end itemize

Portability problems fixed by Gnulib module @code{stdio} or @code{vprintf-posix}, together with module @code{nonblocking}:
@itemize
@item
When writing to a non-blocking pipe whose buffer is full, this function fails
with @code{errno} being set to @code{ENOSPC} instead of @code{EAGAIN} on some
platforms:
mingw.
@end itemize

Portability problems fixed by Gnulib module @code{stdio} or @code{vprintf-posix}, together with module @code{sigpipe}:
@itemize
@item
When writing to a pipe with no readers, this function fails, instead of
obeying the current @code{SIGPIPE} handler, on some platforms:
mingw.
@end itemize

Portability problems not fixed by Gnulib:
@itemize
@item
Attempting to write to a read-only stream fails with @code{EOF} but
does not set the error flag for @code{ferror} on some platforms:
glibc 2.13, cygwin 1.7.9.
@end itemize