-----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 [EMAIL PROTECTED]
-----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-----
