When using running both Undefined Behavior Sanitizer (UBSan) and
Hardware-Assisted Address Sanitizer (HWASan) on Fuchsia, ubsan
complained about a pointer overflow when computing the new token->name pointer.
This happens because the initial pointer diff takes the offset between
two allocations with different tags, so the arithmetic results in a very
large diff that gets added to the original token->name ptr which
overflows.
Any arithmetic between pointers to two allocations is unspecified
behavior, so hwasan+ubsan is catching a bug here. It looks like
rapidjson is just attempting to update the name pointers to strings
copied into the new nameBuffer_ via this arithmetic, but since these
strings and the tokens are in the same buffer, the offset between them
should be the same. For each token we can just get this offset and
adjust the new name pointers accordingly which avoids the bad arithmetic.
A change to the semantics of equality operator rewriting in C++20 (P2468R2: The Equality Operator You Are Looking For) means that operator== may not be rewritten with reversed operands if operator!= is also defined. Since operator!= can normally be synthesized from operator== regardless in this language standard, we can and should avoid defining those when the new language semantics are available.
This fixes the compilation of tests (and probably consuming code) in C++20 onwards for compilers that implement this new semantic, including recent nightly builds of clang-16.
Reference: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2468r2.html
Fixed DigitGen to use proper suffix for uint64_t numeric types. Change from U suffix to ULL suffix.
On SLED 11.0 compiler, code would not compile.
cd rapidjson-master
g++ -Wall -m32 -ggdb -Iinclude -O1 ./example/simpledom/simpledom.cpp -o simpledom 2>&1 | tee out.txt
Fixing compiler error on older compilers, such as SLED 11.0.
cd rapidjson-master
g++ -Wall -m32 -ggdb -Iinclude -O1 ./example/simpledom/simpledom.cpp -o simpledom 2>&1 | tee out.txt
Changed SIZE_MAX to std::numeric_limits<size_t>::max() in code to get rid of SIZE_MAX error.
These operators call themselves recursively if C++20 semantics are present in the compiler, regardless of standard library support for the operator; therefore the test should be on __cpp_impl_three_way_comparison, not __cpp_lib_[...].
This fixes the Value.EqualtoOperator test when the language standard is set to C++20 and the standard library does not yet define the library support macro.
operator[]() was recently changed to use the existing code in order to
correctly align the returned pointer; however this broke
-Wexit-time-destructors. Change to a method that is still correctly
aligned but does not generate a destructor.
operator[]() was recently changed to use the existing code in order to
correctly align the returned pointer; however this broke
-Wexit-time-destructors. Change to a method that is still correctly
aligned but does not generate a destructor.
Fixes 2 compile errors with gcc-12, eg:
tesunittest/valuetest.cpp:1516:30: error: 'sprintf' may write a terminating nul past the end of the destination [-Werror=format-overflow=]
test/unittest/valuetest.cpp:1516:20: note: 'sprintf' output between 2 and 11 bytes into a destination of size 10
Add the typedef declaration `StackAllocatorType` to the class template
`GenericDocument`. This allows the user to access the template parameter
`StackAllocator`.
When using operator[] on a GenericValue type clang-tidy complains,
appropriately, about the alignment of the buffer used for placement-new
of the "dummy" GenericValue.
When using operator[] on a GenericValue type clang-tidy complains,
appropriately, about the alignment of the buffer used for placement-new
of the "dummy" GenericValue.
