Mercurial > hg > octave-nkf > gnulib-hg
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