On 07/04/2012 04:14 AM, Peter Krempa wrote:
>>>> @@ -460,6 +460,9 @@ _vshCalloc(vshControl *ctl,
size_t nmemb,
>>>> size_t size, const char *filename, int
>>>> {
>>>> char *x;
>>>>
>>>> + if (!size)
>>>> + return NULL;
NACK to this; vshCalloc is defined as always returning non-NULL if it
returns (even if it is a dummy malloc(0), assuming glibc semantics where
you get a 1-byte allocation after all).
>> But assuming that 0 elements of something will never overflow
we
>> could change the macro to:
>>
>> from:
>> # ifndef xalloc_oversized
>> # define xalloc_oversized(n, s) \
>> ((size_t) (sizeof(ptrdiff_t) <= sizeof(size_t) ? -1 : -2) / (s)
>> < (n))
>> # endif
>>
>> to:
>> (s?((size_t) (sizeof(ptrdiff_t) <= sizeof(size_t) ? -1 : -2) / (s)
>> < (n)):0)
NACK to this; this macro was copied from gnulib, and any changes should
be made in gnulib first. But you'll have a hard time changing gnulib,
since...
I found the actual problem for this. I think that this macro is in
order. S is the size of the array element, which doesn't make sense to
be 0 and N is the count of elements. The floating point exception
happened because the count and size arguments were interchanged in the
problematic place.
This is the real problem. We were using the macro incorrectly, and it
is not a bug in the macro itself.
I'll send the patch anyways, but I don't think now,
that the macro requires fixing.
Agreed - leave the macro alone.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org