>>> Not if the math overflowed down to a smaller value before it even got
>>> passed
>>> to reserveCapacity().
>>
>> Ok. I'm going to check minSpace. maxSize+minSpace is definitely not
>> enough to overflow size_type
>
>
> minSpace is controlled completely by the unknown caller code. It may be
> UINT_MAX or something equally capable of overflowing when you add to it.
What is currently done is:
reserveSpace(minSpace) {
reserveCapacity(length()+minSpace);
}
reserveCapacity(minCapacity)
{
Must(0 <= minCapacity <= maxSize); // maxSize is 0xfffffff, 256Mb
cow(minCapacity);
}
cow(newsize) //it's private
{
if(!need_to_resize()) return;
reAlloc(newsize);
}
reAlloc(newsize) { // it's private
Must (newsize < maxSize);
}
> I think the right check for here is:
> if (maxSize - length() < minSpace || minSpace < 0) abort().
>
> The math being done on the two values we are confident about already and
> ensuring that the leftover space is enough for the caller.
I'm currently checking 0<=requestedSpace<=maxSize;
worst case is that if someone requests
reserveSpace(maxSize);
the exception will be triggered in reserveCapacity() instead of
reserveSpace() as the length()+requestedSpace will be checked there.
I am convinced that a few of these checks are redundant, but CPU power
is cheaper than brainpower.
> The extra 0 check disappearing when we move to unsigned of course.
Yes.
-- /kinkieReceived on Wed Jul 31 2013 - 16:12:33 MDT
This archive was generated by hypermail 2.2.0 : Wed Jul 31 2013 - 12:00:07 MDT