j is a ssize_t, which can go negative. If it goes negative,
the resulting multiplication of mItemSize*j doesn't make
any sense. Since the value is never used, just don't perform
the calculation if j < 0.
Bug: 23607865
Change-Id: I14f6f6506645d582f7d67a2e2d60ead3cb18b957
* Hashing functions rely on integer overflow behavior.
Mark those functions as safe.
* abort() if a passed in size_t value is greater than
UINT32_MAX. This can occur on 64 bit builds where size_t
is larger than uint32_t.
* Special case the index lookup for an empty sorted vector.
Without the special case, size() == 0, and size()-1 underflows.
Change-Id: I343a14b589fc8f0d221c1998ae5d6f0b9e2781f8
1. When alloc or realloc failed in the function SharedBuffer::editResize,
it would return a NULL pointer, then mStorage would update to be 1 by
SharedBuffer::data() if no pointer check here, which is an obviously
wrong address, and would cause corruption when used it e.g. in capacity().
So add the pointer check here for the return value of SharedBuffer::editResize,
if it's NULL do not use it to update mStorage, to avoid the value of mStorage
polluted.
2. when alloc or realloc falied in _grow & _shrink function, mStorage keep
the original value, so mCount should not be updated here.
Otherwise, mStorage might be 0 but mCount>0, so a corruption would happend
when it try to delete items from the Vector since mCount>0.
Change-Id: I7c3814e843c459834ca5eed392e8d63d1cb7d2d8
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Jian Luo <jian.luo@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 139626