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