MacOS X 10.7 added an fdatasync syscall and exports a symbol for it,
but fails to declare it anywhere. Lacking any hard evidence that this
syscall is broken, we will just provide the declaration and use it.
* m4/fdatasync.m4 (gl_FUNC_FDATASYNC): Check for present but not
declared.
* m4/unistd_h.m4 (gl_UNISTD_H_DEFAULTS): Another default.
* modules/unistd (Makefile.am): Substitute it.
* lib/unistd.in.h (fdatasync): Declare on MacOS.
* doc/posix-functions/fdatasync.texi (fdatasync): Document it.
Signed-off-by: Eric Blake <eblake@redhat.com>
At least libvirt would like to use the lighter-weight fdatasync
on platforms where it is supported, while still guaranteeing full
sync (via the heavy-weight fsync fallback) on all platforms.
I've got an open question to the Austin Group, since the POSIX 2008
wording is self-contradictory (unlike fsync, fdatasync requires
EBADF on non-writable fds, but still mentions that read() errors
must be propagated). I can see how fsync() would affect atime after
read() while fdatasync() can skip that, explaining why fdatasync()
might have the EBADF requirement, but on the other hand, that prevents
an implementation (like ours) where fdatasync is a straight alias of
fsync. At any rate, glibc allows fdatasync on read-only fds.
* modules/fsync (Description): Document difference to fdatasync.
* modules/fdatasync: New module.
* m4/fdatasync.m4 (gl_FUNC_FDATASYNC): New file.
* lib/fdatasync.c (fdatasync): Likewise.
* m4/unistd_h.m4 (gl_UNISTD_H, gl_UNISTD_H_DEFAULTS): Set up
defaults.
* modules/unistd (Makefile.am): Set witnesses.
* lib/unistd.in.h (fdatasync): Declare.
* MODULES.html.sh: Document it.
* doc/posix-functions/fdatasync.texi (fdatasync): Likewise.
* modules/fdatasync-tests: New test.
* tests/test-fdatasync.c: Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
* m4/printf.m4 (gl_PRINTF_INFINITE_LONG_DOUBLE): Don't guess yes on
MacOS X; the test fails on MacOS X 10.5.8.
* doc/{glibc,posix,pastposix}-{headers,functions}/*.texi: Update info
about MacOS X.
