Older GCC versions fail compiling RapidJSON due to a warning
include/rapidjson/reader.h:578: error: suggest a space before ';' or explicit braces around empty body in 'while' statement
: warnings being treated as errors
From the Debian wiki: https://wiki.debian.org/X32Port
X32 is an ABI for amd64/x86_64 CPUs using 32-bit integers, longs
and pointers. The idea is to combine the smaller memory and cache
footprint from 32-bit data types with the larger register set of
x86_64. The 64-bit registers can make computation more efficient,
and with 8 additional registers available, there is less pressure
compared to i386/i686.
rapidjson makes an incorrect assumption in a check for 64 bit
platforms, and uses __LP64__ exclusively. This fix adds an
additional check for __x86_64__ && __ILP32__ defines, as a very
conservative fix. However, the usage of __LP64__ would be a problem
for other "mixed" applications like ARM ILP32, so a better detection
scheme might be needed in the future.
also use internal::StrLen to get the string lengtht,
when it call FindMember(StringRef(name)).
Now use GenericValue construct it, then can use the std::string.size.
now it will be faster.
Prior to this change, a user could incorrectly pass a Document object to
SchemaValidator. This would implicitly construct a SchemaDocument, which
would then be destructed before the validator was used. This caused
unpredictable results including memory corruption and program crashes.
Fix inconsistent calling of template functions in PutN in stream.h. When
used with a GenericStringBuffer<<UTF8>, MemoryPoolAllocator>, PutN would call
PutReserve from stream.h, and PutUnsafe from stringbuffer.h. This
resulted in bytes being added to the buffer without allocating space.
This was not an issue when used with the default memory allocator,
because in this case the specialized PutN is used from stringbuffer.h.
UBSAN gave in Value.IsLosslessFloat:
include/rapidjson/document.h:981:38: runtime error: value 3.40282e+38 is outside the range of representable values of type 'float'
note that std::numeric_limits<uint64_t>::max() and
std::numeric_limits<int64_t>::max() aren't exactly representable in a
double, so we need to be strictly less to be definitely lossless
UBSAN gave during Value.IsLosslessDouble test:
include/rapidjson/document.h:955:42: runtime error: value 1.84467e+19 is outside the range of representable values of type 'unsigned long'
UBSAN gave during Reader.ParseNumber_FullPrecisionDouble test:
include/rapidjson/internal/strtod.h:149:11: runtime error: shift exponent 46 is too large for 32-bit type 'int'
