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

[Tim Van Holder]

> > | I'd also like to place the PARAMS macro in its own
> > | little header file; it's currently duplicated in several places...
> 
> I'm of two minds about this.  Part of me wants K&R C go away.  K&R C
> is no longer supported by many GNU applications.  I've dropped support
> for it on all the apps that I am the principal maintainer for, and
> have not received one complaint.  There are some holdout apps, but I
> suspect they'll give up on K&R C sooner or later.  In the meantime,
> perhaps it's better if we just replicate PARAMS everywhere rather than
> codify it into a separate little tiny file that will go away one of
> these days anyway.

Fair enough.

> I'd rather not put this stuff in the mainline code, as it complicates
> it unnecessarily.  I would rather have something like this:
> 
> #ifndef ISSLASH
> # define ISSLASH(C) ((C) == '/')
> #endif
> 
> and then let config.h override it.  Similarly for 
> FILESYSTEM_PREFIX_LEN.
> Again, please see dirname.h in fileutils 4.1.5.

Good enough for me.  One small point though: would those macros be meant
for the user as well, or just for internal use by dirname.c?
It's just that for non-Unix systems, it's hard (if not impossible) to
write a macro that does TRT without evaluating arguments twice (without
relying on gcc extensions anyway).  If we control the use of the macro,
that's fine, but if it's for public use, it may need to be more robust.
So we may want is_slash() and filesystem_prefix_len() functions instead
of macros.  is_slash() is easy enough; if an autoconf macro provides
DIRSEP1 and DIRSEP2 #defines, the argument simply gets checked against
both (ISTR something similar is done in gcc or binutils sources).
I'm not sure how a macro could properly handle the other function
though;
I'm afraid that in order to get a working solution you'd need platform
conditionals for that one.