As per discussion in - https://github.com/open-source-parsers/jsoncpp/issues/404
Null should not be pass to memcmp, it may show undesired behaviour, so avoid doing that using assertion.
Also, changed one direct "assert" to JSON_ASSERT - it will be decided if exceptions are used or not.
See https://github.com/open-source-parsers/jsoncpp/issues/411#issuecomment-180974558
I was unable to produce a warning in Clang, so I am not certain. But based on a [SO answer](http://stackoverflow.com/questions/25480059/gcc-conversion-warning-when-assigning-to-a-bitfield), I think I've fixed the following:
```
/tmp/jsoncpp/src/lib_json/json_value.cpp: In copy constructor 'Json::Value::CZString::CZString(const Json::Value::CZString&)':
/tmp/jsoncpp/src/lib_json/json_value.cpp:235:18: error: conversion to 'unsigned char:2' from 'unsigned int' may alter its value [-Werror=conversion]
storage_.policy_ = (other.cstr_
~~~~~~~~~~~~
? (static_cast<DuplicationPolicy>(other.storage_.policy_) == noDuplication
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
? noDuplication : duplicate)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: static_cast<DuplicationPolicy>(other.storage_.policy_));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
* Add move constructor to Value::CZString
* Add unit test for Value move constructor
* Allow includer to specify in advance the value for
JSON_HAS_RVALUE_REFERENCES
In value.h, ValueConstIterator can convert to ValueIterator, I think that is a bug. the correct way is ValueIterator can convert to ValueConstIterator.
Based on a patches to CMake by:
Ådne Hovda <ahovda@openit.com>:
commit 7b1cdb00279908cacabada92f8a53e4986465423
jsoncpp: Provide 'isfinite' implementation on older AIX and HP-UX
Newer AIX and HP-UX platforms provide 'isfinite' as a <math.h> macro.
Older versions do not, so add the definition if it is not provided.
Michael Scott <michael.scott@gbgplc.com>:
commit 9217b678b305d7df7471ba476a81bf28961fdfa3
jsoncpp: Provide 'isfinite' impl on more HP-UX versions (#15576)
Some versions of HP-UX do not define 'isfinite' or 'finite' in math.h
for Itanium when preprocessing with C++, so we have to add the
definition ourselves instead to map to the internal version.
Joerg Sonnenberger <joerg@bec.de>:
commit 75644dafe54c21902f14cfe58cb8338b553b69d8
jsoncpp: Fix compilation as C99 on Solaris
In C99 mode, Solaris variants may already define isfinite, so check for
the existence first.
At all 3 places isMultiLine is checked in for loop :
for (int index = 0; index < size && !isMultiLine; ++index) {
It means !isMultiLine is always true (otherwise do not enter loop), so || condition does not depend on isMultiLine, so removed that.
Introduce 'allowSpecialFloats' for readers and 'useSpecialFloats' for writers, use consistent macro snprintf definition for writers and readers, provide new unit tests for #209
Introduce 'allowSpecialFloats' for readers and 'useSpecialFloats' for writers, use consistent macro snprintf definition for writers and readers, provide new unit tests for #209
Otherwise, on some 32 bit platforms this may not fit into long and compilation will fail:
src/test_lib_json/main.cpp:1260: error: integer constant is too large for 'long' type
* Clean up closing statements for if conditions, functions, macros,
and other entities. Newer versions of CMake do not require you to
redundantly respecify the parameters to the opening arguments.
We had already fixed Value to hold UTF-8 properly, but only the newer
StreamWriter was writing UTF-8 properly.
Old FasterWriter etc. were using asCString() instead of asString() in
Value::writeValue().
Hopefully this change does not break any existing code. Seems unlikely.
issue #240
This reverts commit 1c58876185.
std::snprintf() is only available in C++11, which is not provided by
all compilers. Since the C library snprintf() can easily be used as a
replacement on Linux systems, this patch changes jsoncpp to use the C
library snprintf() instead of C++11 std::snprintf(), fixing the build error
below:
src/lib_json/json_writer.cpp:33:18: error: 'snprintf' is not a member of 'std'
See #231, #224, and #218.
