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

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

I can quickly grep my sources for uses of functions whose semantics
change.  But last time we played the naming game with this code, where we
changed base_name from non-mallocing to mallocing (and introduced
last_component), I know that it was more than a year before several gnulib
clients fixed their memory leak that had been silently introduced by the
rename.  At this point, I'd much rather cause a hard compiler error, which
forces the issue to be visited.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki36JIACgkQ84KuGfSFAYBAoQCgvcGSUQ8rmlTMQbM3zOVjWkui
cisAn3s3Csw7LvUk5e+Z1bNiqb/oTGT2
=+2Xh
-----END PGP SIGNATURE-----