Re: gnulib broken on systems lacking fchdir

[Matthew Woehlke]

Eric Blake wrote:
> According to Matthew Woehlke on 11/29/2006 4:48 PM:
> > 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.

I have no problem making anything I write LGPL, especially as I expect 
it to be pretty trivial. The main issue would be gl_list (as per 
comments below), but maybe I'll just use that and call my code LGPL but 
with a GPL dependency. Then if anyone needs an LGPL fchdir, it'll be 
their problem to rip out gl_list and put in something else. :-)

> > 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.

That sounds like a good idea, but... does that mean I have to *write* an 
entire unistd.h *and* make it work everywhere, or is there a way to 
'drop in' one that pulls the system unistd.h, plus extras?

> > 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.

As mentioned, so far this has nothing to do with coreutils except that I 
know it *will* affect coreutils. Right now I'm worrying about gzip. :-) 
But... I'm also planning on building gettext (albeit not a version that 
has the newer *at stuff AFAIK). I don't *expect* anyone to be building 
non-GPL software using gettext (not on this platform, certainly!) but 
maybe 'better safe' would be preferable here.

Back to the technical standpoint, come to think of it don't most systems 
limit # of fd's to a reasonable number like 1024? IOW something that 
allocating a fixed array, even if it had to be large enough to hold all 
possible fd's, would not be unreasonable on modern (i.e. > 64 MB memory) 
systems? Else an indirection table (24:8 with the upper table 
dynamically sized) would certainly keep things under control. That would 
give O(1) access and deletion and O(1)*O(malloc()) (with average O(1)) 
insertion, without allocating one huge block of memory for a sparse list.

--
Matthew
"Lost a planet, Obi Wan has? How embarassing..."
 -- Yoda (Star Wars II: Attack of the Clones)