bug-gnulib
[Top][All Lists]
Advanced

[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: Jim Meyering
Subject: Re: findprog: don't exit => exit-free base_name, dir_name, etc
Date: Fri, 29 Aug 2008 14:23:18 +0200

Eric Blake <address@hidden> wrote:

> According to Jim Meyering on 8/29/2008 6:00 AM:
>>> 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.
>
> We have the NEWS file to mention that.  But how about we go one step
> further, and have a deprecation period, where for a year or so, we provide
> mbase_name (returns NULL on failure) and xbase_name (calls xmalloc on
> failure) but no base_name.  Then clients will be forced to fix their code,
> and choose the semantics they desire.  After a deprecation period, we
> could then either rename mbase_name to base_name, or provide base_name as
> an alias for mbase_name, completing the naming consistency.  Hopefully by
> that time all gnulib clients will have updated their code.

That would be fine with me.
As you say, a year may not be enough, but we can revisit
this again, then, prodding any project listed in users.txt that
has not yet converted.




reply via email to

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