The Pointer passed to construct the Schema can be from the stack or any
transient storage, so the copy stored in the Schema must have the same
lifetime/allocator as the Schema itself.
Speed is more important than alphabetical order (which makes few sense in
JSON in general, and with pointers especially). The use case is indexing
in std containers, i.e. O(log n) with rbtree, so the faster comparison
the better.
I must be too dumb to understand the mess MSVC (32bit only) did with the
previous loop, and to figure out how it might have make it never end.
Anyway, hopefully any compiler can grok this new loop...
On (my) linux, perftest reports:
- ~40% gain for FileReadStream (Take() loop),
- ~10% gain for ReaderParse_DummyHandler_FileReadStream.
With the same logic applied to BasicIStreamWrapper, which thus can now
also be created with a user buffer, performances align with those of
FileReadStream (same buffer size).
The "unbuffered" versions (added for FileReadStream) work solely with
the internal peekBuffer (Ch[4]) and are measured in perftest. When
performances don't matter much, they can avoid the use of large
stack/heap buffers.
Because `isPeek()` is side effect free this should not change anything.
The reason this warning is not shown in the unit tests is because the asserts
are always evaluated in the unit test:
#define RAPIDJSON_ASSERT(x) (!(x) ? throw AssertException(RAPIDJSON_STRINGIFY(x)) : (void)0u)
The existing checks triggered undefined behavior when the stack was empty (null pointer). This change avoid this:
* If `stackTop_` and `stackEnd_` are null, it results in a `ptrdiff_t` of `0`
* If `stackTop_` and `stackEnd_` are valid pointers, they produce a `ptrdiff_t` with the remaining size on the stack
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.
Recent GCC versions warn about using memcpy/memmove to
write to a class pointer (-Wclass-memaccess).
Avoid the warnings by casting to void* first.
Closes#1086.
Closes#1205.
Closes#1246.
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.
