[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: extend the scope of xasprintf
From: |
Paul Eggert |
Subject: |
Re: extend the scope of xasprintf |
Date: |
Tue, 09 May 2006 00:35:24 -0700 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
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.
Re: [bug-gnulib] Re: extend the scope of xasprintf, Bruno Haible, 2006/05/09