Update RAPIDJSON_ALIGN() to always align on an 8-byte boundary
unless otherwise overridden.
On some platforms (such as ARM), 64-bit items (such as doubles and
64-bit integers) must be aligned to an 8 byte address, even though the
architecture is only 32-bits. On these platforms, MemoryPoolAllocator
must match the malloc() behavior and return a 8 byte aligned allocation.
This eliminates any alignment issues that may occur at the expense of
additional memory overhead.
Failure to do so caused a SIGBUS signal when calling
GenericValue::SetNull(). The size of the data_ member of the
GenericValue class is 16 bytes in 32-bit mode and its constructor
requires an 8-byte aligned access.
While parsing a JSON formatted string using Document::ParseStream(), a
stack object containing GenericValue items was constructed. Since the
stack was 8-byte aligned, the constructor calls would succeed. When the
lifetime of the object ends, SetObjectRaw() is invoked. This triggered
an allocation with 4-byte alignment to which the previously 8-byte
aligned GenericValue array was copied. After this, any call to a
GenericValue API that triggered the constructor and thus the placement
new operation on the Data type member would trigger a SIGBUS.
Signed-off-by: Veselin Georgiev <veselin.georgiev@garmin.com>
Signed-off-by: Joshua Watt <Joshua.Watt@garmin.com>
GCC 8 (incorrectly) warns about sign conversions in (constant)
array size expressions:
error: conversion to 'long unsigned int' from 'int' may
change the sign of the result [-Werror=sign-conversion]
char schemaBuffer_[128 * 1024];
Make these expressions unsigned by adding a 'u' suffix to
the first operands.
Sometimes, particularly when Microsoft's windows.h is included, min/max
are defined as macros, interfering with use of
std::numeric_limits::min() and the like.
To guard against this, the function name is wrapped in an extra set of
parenthesis, which inhibits function-style macro expansion.
This is a similar commit to 6e38649ec6, but fixes uses of
std::numeric_limits added after that commit, like those introduced in
2ea43433e2.
When parsing negative exponents, the current implementation takes
precautions for |exp| to not underflow int.
But that is not sufficient: later on [1], |exp + expFrac| is also
stored to an int - so we must ensure that the sum stays within int
representable values.
Update the exp clamping logic to take expFrac into account.
[1] https://github.com/Tencent/rapidjson/blob/master/include/rapidjson/reader.h#L1690
