Re: [Bug-gnulib] Re: Bug in getloadavg

[Jim Meyering]

Bruno Haible <address@hidden> wrote:
> Paul Eggert wrote:
>> +  old_locale = xstrdup (setlocale (LC_NUMERIC, NULL));
>
> Since setlocale can return NULL (or, at least, the replacement stub for
> absent setlocale is NULL) and xstrdup (NULL) is invalid, I would rewrite
> this as
>
>      old_locale = setlocale (LC_NUMERIC, NULL);
>      if (old_locale != NULL)
>        old_locale = xstrdup (old_locale);
>
>> /* Set the `FD_CLOEXEC' flag of DESC if VALUE is true,
>>    or clear the flag if VALUE is false.
>>    Return true on success, or false on error with `errno' set. */
>>
>> bool
>> set_cloexec_flag (int desc, bool value)
>
> Maybe I'm the only one, but I have a problem with functions returning
> 'bool' and errno. Namely, the calling convention is just the opposite
> of so many Unix functions, like close(), shmdt() etc. For all these
> functions 0 means success and -1 means failure. I would find a calling
> convention

You're certainly not the only one, ... but we might grow out of it :)
I have the same reflex (and even initially did as you suggest in the new
coreutils/lib/readtokens0.c), but have come to the conclusion that using
`bool' for success/failure return values is a little bit cleaner --
enough to merit the change of paradigm.  Whereas with Unix-style
functions, we sometimes have to know whether to test for -1, EOF, or
simply non-zero, with a `bool'-returning function, it's more intuitive
that `true' means success.  I find that uses of the bool-returning
functions are more readable.  But bear in mind that even after all these
years, I sometimes have to re-read code that does this:
  if (stat (...)) { /* handle failure */ ... }
Sure, we tend to get used to it, but it seems fundamentally unclean
when the return value is conceptually boolean.
Of course, although we all know that this sort of stylistic decision is
a personal choice, and we can't expect everyone to see the same light,
it would be nice if we could come to some sort of agreement on guidelines
for new code.

In spite of all of that, I'm hardly on a crusade...