Re: gnulib broken on systems lacking fchdir

[Matthew Woehlke]

Jim Meyering wrote:
> Matthew Woehlke <address@hidden> wrote:
> > Jim Meyering wrote:
> ...
> > > I did a survey, some time ago, of reasonable porting targets, and all
> > > had fchdir.  Eventually I should remove the test for fchdir, too.
> > So NSK/OSS has just been demoted to 'unreasonable'? Or can we go with
> > Bruno's suggestion and implement a wrapper ala Cygwin?
>
> A well-written fchdir module would be welcome.  Such a module would have
> no effect on coreutils proper, other gnulib modules, or any system with
> fchdir support.

Ok, thanks... Anyway, here's a start:

struct fd_heap_node {
  int fd;
  const char * path;
}

int
fchdir (int fd)
{
  struct fd_heap_node n = fdheap_get(fd);
  if (!n)
    {
      errno = EBADF;
      return -1;
    }
  return chdir (n->path);
}

int
open (const char* pathname, int flags)
{
  int fd = SYS_open (pathname);
  if (fd >= 0)
    fdheap_add (fd, pathname);

  return fd;
}

int
close (int fd)
{
  int res = SYS_close (fd);
  if (res == 0)
    fdheap_del (fd);

  return res;
}

...but as I said, I'm not really familiar with how one needs to overload 
open()/close(), or if fopen()/fclose() and who-knows-what-else also need 
to be overridden. :-)

What about the FD table; should it be a hash table, a binary tree, an 
ordered linked list, or something else entirely?

(Can autotools make compilation of this dependent on HAVE_FCHDIR so that 
it doesn't need to be in One Big Preprocessor Condition? Am I guessing 
right that this - with overloading open()/close() correctly - would mean 
that no header is needed?)

--
Matthew
Emacs is a nice OS - but it lacks a good text editor.
That's why I am using Vim.  -- Anonymous