Eric Blake <[EMAIL PROTECTED]> 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.
