Re: should asprintf and friends guarantee sane pointer on failure?

[Bruno Haible]

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