Hi Jim,
> ended up with
> a new module, mfilenamecat (wrapper around filenamecat), and mfilename
> (contents of basename.c and dirname.c, adjusted not to exit).
This would also solve a problem that was mentioned some time ago: 'argp'
is an LGPLed module, but it uses 'dirname' which is not under LGPL.
> I wanted a version of findprog that I could use from a library
> (libvirt), but the existing one can call exit in several ways.
>
> My first cut at this changes findprog itself not to call exit anymore.
> Obviously, this is an API change, and may well be undesirable, in which
> case I can easily create a new module, say mfindprog, and make findprog
> a trivial wrapper around that new function. Bruno, let me know which
> you'd prefer.
I have no objections against putting the 'findprog' code under LGPL.
But I have two comments about this patch:
1) About the naming of the functions. We have one convention so far to
distinguish a library-safe function and one that calls xalloc_die()
upon memory allocation error: the prefix "x" ("checking").
Using the prefix "m" for the opposite convention makes the code harder
to read in the long run. I'm strongly in favour of sticking with the
"x" convention - even if it means to change all callers of the
existing functions. Such a change is done in a day or week, whereas
an inconsistent naming convention stays forever.
2) For a long time, the 'dirname' and 'filenamecat' modules (from you) and
the 'filename' (from me) were sitting side by side, and coreutils was
using your modules whereas gettext was using mine. If you now propose
patches to make gettext use both 'dirname'/'filenamecat' and 'filename',
I think it's time to work on merging the two codes. Would you agree that
I propose patches to this effect (small patches, one step after the other)?
Bruno
