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

[Jim Meyering]

Bruno Haible <address@hidden> wrote:
...
> 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.

Thanks.

> 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.

I wouldn't mind switching all of my base_name, dir_name, file_name_concat
uses to xbasename, xdirname, xfile_name_concat.  However, changing
the semantics of the existing may-exit functions never to exit feels
too risky.  If someone neglects to rename an existing use, this change
silently introduces a bug, since existing callers have a guarantee that
those functions never return NULL, while the never-exit versions return
NULL upon allocation failure.

That's why I prefer to have a new name for each of the never-exiting
functions.  While I am confident that all of us here can adjust all of
the uses in projects we maintain, it's risky for those who don't follow
development as closely.  What do others think?  If enough people prefer
not to add the "m" prefixes, and thus to keep e.g., base_name and dir_name,
but make them never-exiting, I'll reconsider.

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

Yes, it'd be good finally to unify those modules.