New unit test which ensures that IterativeParseNext always generates
exactly one element at a time, and that calling IterativeParseNext on a
complete document is harmless and generates zero events.
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.
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'
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'
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.
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.
