Hi Eric,
I see two — mostly unrelated — topics in your mail and the referenced
threads.
1) The coding paradigm.
30 years ago I saw a piece of code from Microsoft, which called
fopen() and assumed that the return value was != NULL.
Nowadays, "Solar Designer" presents us code like this:
char *text;
vasprintf (&text, format, args);
that ignores the return value of vasprintf, observes that it is
unsafe, and claims that the behaviour of vasprintf should be
changed.
This is not convincing me. Proper coding with C APIs implies to
*check the return values*.
The only reasonable change that should be done is to mark the
declaration of asprintf and vasprintf with attribute
__warn_unused_result__. This way, the compiler will warn about
the crappy code.
2) The behaviour of asprintf() and vasprintf().
What can happen with the result pointer ptr if
asprintf (&ptr, ...)
fails? There are four possibilities:
(a) ptr is unchanged.
(b) ptr is set to NULL.
(c) ptr is set to a non-NULL pointer that is not free()able.
(d) ptr is set to a non-NULL pointer that is freshly allocated
and thus meant to be freed.
It is quite obvious that no reasonable implementation will do (c) nor (d).
(c) because that would be an invitation for doing free(invalid_pointer).
(d) because what if the function cannot do this fresh allocation, since
memory is tight?
The manual page referenced by
<https://bugs.freedesktop.org/show_bug.cgi?id=90017>
allows all of (a), (b), (c), (d), and shows a case where code would
be buggy if an implementation would do (c).
POSIX
<https://pubs.opengroup.org/onlinepubs/9799919799/functions/asprintf.html>
quote: "For asprintf(), if memory allocation was not possible, or if
some other error occurs, the function shall return a negative
value, and the contents of the location referenced by ptr are
undefined, but shall not refer to allocated memory."
allows (a), (b), (c), but not (d).
So, I hope everyone agrees that neither glibc nor gnulib should do
(c) or (d).
The traditional behaviour is (a).
I have no strong objections regarding (b). Assigning NULL is just
unnecessary: A programmer who wants ptr == NULL in case of failure
can just assign 'ptr = NULL;' before the call.
Florian Weimer can add extra '*resultp = NULL;' assignments in glibc,
if he likes to, for the sake of crappy user code that does not check
return values. But I don't think this needs to become commonplace,
and in particular I don't think Gnulib needs that.
Bruno
