The atomic writev emulation in sysdeps/posix/writev.c (and likewise readv) depends on being able to obtain a potentially-large buffer via malloc, and fails when memory is unavailable. It would be much nicer to have an automatic buffer of size PIPE_BUF for use when malloc fails, and simply write at most PIPE_BUF bytes in that case. This is permitted behavior, per POSIX; writes on non-pipes are not required to be atomic, and writes on pipes need only be atomic if the size to be written is bounded by PIPE_BUF. Aside from that case, "short writes" (and likewise, for readv, "short reads") are permitted, and it's the caller's responsibility to resubmit the rest if desired. I have no idea if this code is actually used anywhere, but it would be nice to fix it anyway, and it could be useful to people porting to obscure systems (especially if the same code is used in newlib..?)
FWIW: /* Pessimistically assume that 2.6.18 introduced real handling of large numbers of requests to readv and writev and that we don't need a fallback. It likely worked for much longer. */ #if __LINUX_KERNEL_VERSION >= 0x020612 # define __ASSUME_COMPLETE_READV_WRITEV 1 #endif It would be nice if someone figured out just when this went into the kernel - if it was actually 2.6.16 or before, then this replacement code isn't actually needed for Linux any more.
This has been addressed indirectly by requiring a minimum kernel version of 2.6.16, starting with glibc 2.17.
This is still an issue with the fallback code present in the glibc source tree (maybe used on Hurd?), although the problem code won't be used on Linux. (The relevant Linux kernel support was actually added between 2.0 and 2.2.)