In the constructor for GenericRegexSearch, there was an issue with a
static_cast casting the result of the Malloc call. The issue was that
the stateSet_ member is of type uint32_t*, and there was an attempt to
assign an unsigned* to it. On some systems, uint32_t is not equivalent
to unsigned, thus yielding a compile error for assigning pointers of
different type.
Change-Id: I5b5036100305510b83cc4893b784a2dc9f3e4849
One of multipleOf test failed because most floating-point numbers end
up being slightly imprecise. And, the check of multipleOf with two
double numbers using the dividend (a) and the result of multiplying
the multiple after rounding down by the divisor (floor(|a|/|b|)*b) to
compare.
Change to using std::numeric_limits::epsilon to check the error of
the division result.
The identifier 'allocator' in the RapidJSON StdAllocator class declaration shadows the identifier 'allocator' in the
std::allocator class. To fix this, rename the 'allocator'
identifier in the StdAllocator class declaration to a different name.
Remove useless comment block which owns a '\see' cross-reference, but
doesn't provide any data after it. This empty cross-reference triggers
a compiler warning.
Change-Id: I5c01d57579e5efedcb4bf17b80b06db313a61ab3
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.
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.
Sergey Fedorov