bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fcntl module


From: Paolo Bonzini
Subject: Re: fcntl module
Date: Sat, 22 Aug 2009 09:23:28 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]