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>

@node lstat
@section @code{lstat}
@findex lstat

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

Gnulib module: lstat

Portability problems fixed by Gnulib:
@itemize
@item
For symlinks, when the argument ends in a slash, some platforms don't
dereference the argument:
Solaris 9.
@item
On some platforms, @code{lstat("file/",buf)} succeeds instead of
failing with @code{ENOTDIR}.
Solaris 9.
@item
On Windows platforms (excluding Cygwin), symlinks are not supported, so
@code{lstat} does not exist.
@end itemize

Portability problems not fixed by Gnulib:
@itemize
@item
On platforms where @code{off_t} is a 32-bit type, @code{lstat} may not
correctly report the size of files or block devices larger than 2 GB.  The fix
is to use the @code{AC_SYS_LARGEFILE} macro.
@item
On Windows platforms (excluding Cygwin), @code{st_ino} is always 0.
@item
Because of the definition of @code{struct stat}, it is not possible to
portably replace @code{stat} via an object-like macro.  Therefore,
expressions such as @code{(islnk ? lstat : stat) (name, buf)} are not
portable, and should instead be written @code{islnk ? lstat (name,
buf) : stat (name, buf)}.
@item
On some file systems, @code{st_size} contains bogus information for
symlinks; use the gnulib module areadlink-with-size for a better way
to get symlink contents.
@end itemize