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