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'
UBSAN on Clang/Linux gave:
runtime error: null pointer passed as argument 2, which is declared to never be null
/usr/include/string.h:43:45: note: nonnull attribute specified here
UBSAN gave issues with the typeless Schema:
runtime error: reference binding to null pointer of type 'rapidjson::GenericSchemaDocument<rapidjson::GenericValue<rapidjson::UTF16<wchar_t>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >, rapidjson::CrtAllocator>'
and
runtime error: member access within null pointer of type 'AllocatorType' (aka 'rapidjson::CrtAllocator')
This adds kWriteNanAndInfFlag to Writer to allow writing of nan,
inf and -inf doubles as "NaN", "Infinity" and "-Infinity",
respectively, and kParseNanAndInfFlag to Reader to allow parsing
of "NaN", "Inf", "Infinity", "-Inf" and "-Infinity". This is part
of issue #36, adding optional support for relaxed JSON syntax.
Trim whitespace off the end of various lines.
Added an additional NumberStream specialization that will always perform a TakePush() even when just Take() is called. This supports RawNumber parsing by pushing onto our StackStream particular parts of the number that currently aren't captured because of full precision double parsing, such as the negative sign, scientific number exponents, etc.
RawNumber parsing fails with input streams that don't have copy optimization, such as the BasicIStreamWrapper stream. To work around this, instead do the Transcode copy operation by reading from a UTF8 StringStream instead of the original InputStream. Since the NumberStream downcasts all input Ch into chars, we know we're dealing with UTF8/ASCII compatible stack characters during the Transcoding.
