Re: extend the scope of xasprintf

[Paul Eggert]

Eric Blake <address@hidden> writes:

>> +   result = (char *) xmalloc (totalsize + 1);
>
> What if totalsize is INT_MAX?

totalsize is of type size_t, so SIZE_MAX is the problem case here, not
INT_MAX.  So I assume you're suggesting that the earlier
"if (totalsize > INT_MAX) ..." be changed to
"if (totalsize > MAX (INT_MAX, SIZE_MAX - 1)) ..."?

How about a different change instead.  Even if the default
implementation cannot handle large strings, that doesn't mean this
code must refuse to handle large strings.  So how about replacing
"if (totalsize > INT_MAX) ..." by
"if (size_overflow_p (totalsize)) ...".

Perhaps some day the default implementation can be fixed to handle
large strings too.

> Also, should we worry about a multithreaded environment, if another thread
> changes the string length between when you malloc'd the buffer and copy the
> contents into the buffer?

Many gnulib routines could not survive in an environment like that.
I wouldn't worry about it here either.

>>   char *
>>   xvasprintf (const char *format, va_list args)
>>   {
>
> Should we be robust to a NULL format?

I don't see why.  The default implementation isn't robust.

> Is it worth recognizing the special case of a format string with no "%"
> formatting directives, and do the equivalent of strdup(format) in that case?

I'd guess not.