First order of business - we need two modules based on the fcntl name, one for the header (as fcntl.in.h does other useful things independently of whether we are fixing cloexec and other fcntl(2) items), and one for the function. If we keep the existing fcntl name as the header, then what should I name the fnctl(2) replacement module? On the other hand, why not rename the header module to fcntl-h, and re-purpose the fcntl module name to cover the function? My preference is the latter, given that we already have a gettext/gettext-h module doing a similar job.
Agreed.
Additionally, most users of fcntl.in.h are via indirect dependencies from other modules, so I doubt many gnulib users are currently directly requesting 'gnulib-tool --import fcntl'. And since the function module will depend on the header module, a client that imports fcntl will still get the fixed header (and they can later choose to import just fcntl-h rather than fcntl to reduce how much gets imported).
Also agreed.
So, with that background, does this patch series look okay so far? I've tested that it passes on mingw, cygwin, and older Linux (I don't yet have access to a machine running new enough kernel/glibc to test O_CLOEXEC or F_DUPFD_CLOEXEC). Also available at:
Will test. Paolo
