Re: [tim-3] Improved DJGPP support in src/files.c

[Tim Van Holder]

On Wed, 2002-01-16 at 09:50, Paul Eggert wrote:
> > From: Tim Van Holder <address@hidden>
> > Date: 16 Jan 2002 08:13:19 +0100
> 
> > > #define ISSLASH(x) (! 
> > > "...............................................\0............................................\0..................................................................................................................................................................."[(unsigned
> > >  char) (x)])
> > 
> > Isn't that charset-specific?
> 
> Sure, but we're talking DOS here aren't we?  It uses ASCII.

Except for say, Japanese versions.  But those cases should be rare.
Also, there's no need for the charset used by the program (and thus sent
to IS_SLASH) to match that of the underlying OS; libiconv and/or libc
locales can take care of those conversions later.

> > Yes and no.  Yes if it's a macro, no if it's a function;
> 
> In programs that I help to maintain, I try to banish all such
> functions to a pc/ or ms/ subdirectory and let the Microsoft-oriented
> folks maintain the contents of those directories using whatever tools
> they like.  The Microsoft-oriented stuff tends to get stale pretty
> quickly, so those subdirectories mostly end up being notes about
> ancient ports.  I don't think these maintenance issues should be
> central to Autoconf.  If it's easy to maintain that stuff, fine; I
> just don't want to spend a lot of our limited time on it.

> > 1) No filesys prefix (\FOO\BAR) -> 0
> > 2) Drivespec (C:\FOO\BAR) -> 2
> > 3) UNC (\\NETWORKSHARE\FOO\BAR) -> len(sharename)
> 
> Hmm, if UNCs are special, the current dirname/basename code doesn't
> work.

UNCs are probably pretty rare, so support for them is not really all
that necessary for day-to-day operations.
And usually they will work just fine with dirname and basename (given a
suitable IS_SLASH); recognizing the first component as a filesystem
prefix is more correct (given that the macro may need to be used outside
basename/dirname), but not really needed for basename/dirname to operate
correctly.

> I suspect a lot of existing GNU code won't work for case 2)
> either.
A great percentage of GNU software has code in place to deal with 2)
(though usually through platform conditionals).

Of course, the easiest way out is to just not override the basename and
dirname that DJGPP provides; it deals with all these issues just fine,
resulting in 0 maintenance on your end.  Are there so many different
ways that vendor dirname/basename break that autoconf can't check for a
broken implementation instead of always overriding it with replacements
from lib/?

AC_FUNC_DIRNAME
  -> if dirname missing or broken: add lib/dirname.c
  -> else '#define dir_name dirname' in config.h

and similar for AC_FUNC_BASENAME