- 17 Oct, 2016 1 commit
-
-
Milo Yip authored
-
- 05 Oct, 2016 1 commit
-
-
Milo Yip authored
Fixes #762
-
- 22 Sep, 2016 1 commit
-
-
Milo Yip authored
Fix #744
-
- 21 Sep, 2016 1 commit
-
-
Milo Yip authored
-
- 19 Sep, 2016 1 commit
-
-
Tallódi Mihály authored
-
- 16 Sep, 2016 1 commit
-
-
Milo Yip authored
Remove mutable which causes reentrant issue
-
- 31 Aug, 2016 1 commit
-
-
niukuo authored
Change-Id: Ia96ddf5746f1c18968e9e086f17fe4a24b8480d7
-
- 30 Jun, 2016 1 commit
-
-
Jason Smith authored
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.
-
- 27 Jun, 2016 1 commit
-
-
Philipp A. Hartmann authored
GCC 6.x doesn't yet support this warning flag, as reported by @ragnar-ouchterlony.
-
- 23 Jun, 2016 1 commit
-
-
Philipp A. Hartmann authored
* document.h * suppress -Wterminate on GCC 6.x and later * simplify warning handling * schema.h * drop RAPIDJSON_NOEXCEPT from GenericSchemaDocument constructor (calls RAPIDJSON_NEW anyway) * simplify warning handling (avoids RAPIDJSON_POP mismatch on Clang) * encodingtest.cpp, istreamwrappertest.cpp * work around -Wdangling-else * readertest.cpp * suppress -Wdangling-else
-
- 14 Jun, 2016 5 commits
-
-
Eli Fidler authored
-
Eli Fidler authored
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'
-
Eli Fidler authored
UBSAN gave: runtime error: division by zero
-
Eli Fidler authored
maybe these tests should just be deleted? UBSAN gave: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long' runtime error: signed integer overflow: -9223372036854775808 - 2 cannot be represented in type 'long'
-
Eli Fidler authored
UBSAN gave for test/unittest/itoatest.cpp:87: runtime error: signed integer overflow: 4611686018427387904 * 2 cannot be represented in type 'long'
-
- 13 Jun, 2016 4 commits
-
-
Eli Fidler authored
UBSAN gave "runtime error: index 13 out of bounds for type 'const uint32_t [10]'"
-
Eli Fidler authored
specifically, "expression with side effects has no effect in an unevaluated context"
-
Eli Fidler authored
clang advises: "note: silence by adding parentheses to mark code as explicitly dead"
-
Eli Fidler authored
-
- 20 May, 2016 1 commit
-
-
Michael Thon authored
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.
-
- 19 Apr, 2016 1 commit
-
-
Milo Yip authored
-
- 17 Apr, 2016 2 commits
- 16 Apr, 2016 7 commits
- 15 Apr, 2016 4 commits
- 06 Apr, 2016 1 commit
-
-
Milo Yip authored
-
- 05 Apr, 2016 1 commit
-
-
Milo Yip authored
-
- 04 Apr, 2016 1 commit
-
-
Milo Yip authored
-
- 31 Mar, 2016 2 commits
- 29 Mar, 2016 1 commit
-
-
Jarred Nicholls authored
Later clang compilers will warn on float -> double promotion because it can add precision. In the context of RapidJSON – especially with its float methods on GenericValue – I think this warning holds no water and should be ignored. 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.
-