On 01/26/2012 12:26 PM, Eric Wong wrote: > I can't think of a safe way to implement > SOCK_CLOEXEC/SOCK_NONBLOCK/O_CLOEXEC as-is in gnulib and have it be > forward-compatible. If we expose the flags in public headers, the OS > authors can eventually add support for these things and the native OS > flags may be incompatible with what gnulib uses.
The same as we've done for other flags (for example, we've implemented O_NONBLOCK for mingw). Basically, if we detect at configuration time that the system didn't have a flag, then we define an unused bit for the flag and also define a witness that gnulib owns the bit; then in our rpl_accept4 function, that witness means that we must strip the bit before calling the underlying function, as well as do the touch-up work. If the OS later defines the flags, we're still okay, whether or not the OS flag matches our bit definition or not - either you reconfigure/recompile the app (and pick up the OS definition), or you continue to pick up the gnulib headers (and get the gnulib bit which never gets propagated to the OS). > > Maybe new functions taking gnulib-specific flags will have to be > created... To some extent, that's what we're already doing - gnulib wires everything through its own replacements, then makes the headers hide the fact that replacements are in use so that the rest of the code can use the normal signatures, as long as they are careful about the caveats such as no atomic FD_CLOEXEC. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
