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
GenericDocument contructor requires a pointer to an Allocator, but GetAllocator() only
returns a reference.
Signed-off-by: Julien Courtat <julien.courtat@aqsacom.com>
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 7 and later warn about overflow/truncation when using
sprintf and related functions with fixed-size buffers.
Suppress the warning in schematest.cpp.
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.
