Re: gnulib broken on systems lacking fchdir

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Matthew Woehlke on 11/29/2006 4:48 PM:
>>> int
>>> open (const char* pathname, int flags)
>>
>> You need to remember the optional mode argument to open.
> 
> I saw that in the manpage, but didn't get it. Last I checked C does not
> support function overloading? So I am not sure how to declare both.

C does not have true overloading, but does have varargs.  Check out
lib/open-safer.c for more details of how to write a replacement for open.

> 
> Well, I stole what glibc's manpage called the arg. :-)

Ah. The glibc maintainers are notorious for not placing the GNU Coding
Standards as their highest priority.  They still prefer K&R prototypes, as
can be seen in the gnulib regex module which tries to sync to glibc.

> I'm
> half-expecting that someone will want to standards-sanitize any code I
> submit, which is fine because I know I don't know the standards very
> well. :-)

Yep - that's what the list review process is for.

> 
> The licensing issue is a more important question; do any of the fchdir
> users need to stay LGPL?

fts-lgpl already has licensing issues that have been brought up this
month, so I don't think you would be making matters any worse by writing a
GPL-only fchdir replacement.  But yes, if fts-lgpl is to work on platforms
lacking fchdir, then maybe we would have to consider making fchdir LGPL as
well.

> 
> As per the above comment, I don't think that is going to work, since
> anyone editing the code then needs to know to use the fchdir-replacement
> functions, which is of course a maintenance nightmare.

The other thing we could do, rather than writing "fchdir.h", is write a
replacement <unistd.h> that takes care of fchdir replacement, similar to
how we already have a replacement <inttypes.h>.  Then, modules that use
fchdir merely need to depend on the fchdir module, and all the magic is
taken care of _without any need to edit fchdir clients_.  That is what
makes gnulib so slick - between <config.h> and replacement headers,
remaining modules can behave as though the function always exists,
regardless of the deficiencies of the underlying platform.

> But now I wonder
> if only replacing opendir() is enough? Will have to check. :-)

Perhaps - it may be that the opendir/dirfd combo is all that would need
directory name tracking.

> 
> Hmm, something I know absolutely nothing about, but at least it sounds
> like something I can use safely ("safe" in the legal sense).

Actually, if you use gl_list, you MUST be GPL, since gl_list is GPL only.
 I guess that would mean that libraries that want to use fts-lgpl just
won't work on platforms that lack fchdir; fortunately, coreutils does not
suffer from the need to use LGPL or looser.

> 
> ...except that a declaration for fchdir() is already provided (hmm,
> sorry, should have mentioned it is the link that dies, not the compile).
> So why would an fchdir.h be needed?

For the same reason as we have lstat.h - it pulls in the system headers
first, then #defines the function to its replacement name, so that we can
override broken lstat implementations.  This same idea can be used to test
a replacement fchdir, by defining a replacement as though the platform
fchdir were broken rather than missing.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFbjlj84KuGfSFAYARAv/3AJ9KWDYxHaG41RBFZYK4FIrKRNznrACghEOr
YhHpNR7lbLelXFZ/mcdPo3A=
=vIcu
-----END PGP SIGNATURE-----