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

[Paul Eggert]

> From: Tim Van Holder <address@hidden>
> Date: 16 Jan 2002 10:22:43 +0100

> > Sure, but we're talking DOS here aren't we?  It uses ASCII.
> 
> Except for say, Japanese versions.

That same table should work even on Japanese versions, since they use
the yen-symbol as a separator, and that has the same integer value as
an ASCII backslash.

> 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

I don't follow this point, but I think it's academic if we are talking
about a DOS port.


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

A major problem I had with basename and dirname was broken Microsoft
ports.  I don't know the Microsoft world well, though.  Since we
switched to using our own base_name and dir_name I really haven't been
following vendor quirks.


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

That wouldn't be reasonable, since the semantics have diverged.
dir_name and base_name are reentrant and never modify their arguments;
that is not true of dirname and basename.  These days, quite a bit of
code relies on the nicer semantics of dir_name and base_name.