[Top][All Lists]

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

Re: gnulib broken on systems lacking fchdir

From: Matthew Woehlke
Subject: Re: gnulib broken on systems lacking fchdir
Date: Wed, 29 Nov 2006 16:30:20 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061025 Thunderbird/ Mnenhy/

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;

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

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

  return fd;

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?)

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

reply via email to

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