[Top][All Lists]

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

Re: findprog: don't exit => exit-free base_name, dir_name, etc

From: Bruno Haible
Subject: Re: findprog: don't exit => exit-free base_name, dir_name, etc
Date: Fri, 29 Aug 2008 13:00:16 +0200
User-agent: KMail/1.5.4

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


reply via email to

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