On CHERI, and thus Arm's Morello prototype, pointers are represented as
hardware capabilities. These capabilities are comprised of not just an
integer address, as is the representation for traditional pointers, but
also bounds, permissions and other metadata, plus a tag bit used as the
validity bit, which provides fine-grained spatial and referential safety
for C and C++ in hardware. This tag bit is not part of the data itself
and is instead kept on the side, flowing with the capability between
registers and the memory subsystem, and any attempt to amplify the
privilege of or corrupt a capability clears this tag (or, in some cases,
traps), rendering them impossible to forge; you can only create
capabilities that are (possibly trivial) subsets of existing ones.
When the capability is stored in memory, this tag bit needs to be
preserved, which is done through the use of tagged memory. Every
capability-sized word gains an additional non-addressable (from the
CPU's perspective; depending on the implementation the tag bits may be
stored in a small block of memory carved out of normal DRAM that the CPU
is blocked from accessing) bit. This means that capabilities can only be
stored to aligned locations; attempting to store them to unaligned
locations will trap with an alignment fault or, if you end up using a
memcpy call, will copy the raw bytes of the capability's representation
but lose the tag, so when it is eventually loaded back as a capability
and dereferenced it will fault.
Since, on 64-bit architectures, our capabilities, used to implement C
language pointers, are 128-bit quantities, this means they need 16-byte
alignment. Currently the various #pragma pack directives, used to work
around (extremely broken and bogus) code that includes jsoncpp in a
context where the maximum alignment has been overridden, hard-code 8 as
the maximum alignment to use, and so do not sufficiently align CHERI /
Morello capabilities on 64-bit architectures. On Windows x64, the
default is also not 8 but 16 (ARM64 is supposedly 8), so this is
slightly dodgy to do there too, but in practice likely not an issue so
long as you don't use any 128-bit types there.
Instead of hard-coding a width, use a directive that resets the packing
back to the default. Unfortunately, whilst GCC and Clang both accept
using #pragma pack(push, 0) as shorthand like for any non-zero value,
MSVC does not, so this needs to be two directives.
Return 1.9.1 functionality where values too large to fit in
double are converted to positive or negative infinity.
Commit 645cd04 changed functionality so that large floats cause
parse error, while version 1.9.1 accepted them as infinite.
This is problematic because writer outputs infinity values
as `1e+9999`, which could no longer be parsed back.
Fixed also legacy Reader even though it did not parse large values
even before breaking change, due to problematic output/parse asymmetry.
`>>` operator sets value to numeric_limits::max/lowest value if
representation is too large to fit to double. [1][2] In macos
value appears to be parsed to infinity.
> | value in *val* | description |
> |--------------------------|-------------|
> | numeric_limits::max() | The sequence represents a value too large for the type of val |
> | numeric_limits::lowest() | The sequence represents a value too large negative for the type of val |
[1] https://www.cplusplus.com/reference/istream/istream/operator%3E%3E/
[2] https://www.cplusplus.com/reference/locale/num_get/get/
Signed-off-by: Tero Kinnunen <tero.kinnunen@vaisala.com>
Co-authored-by: Tero Kinnunen <tero.kinnunen@vaisala.com>
When the static libary is available use it as exported alias, otherwise use shared library. Cmake takes care about import library when Windows platform DLL is used
CMake provides helpers to generate config file. Generated config file has usefull macro check_required_components() to set necessary variables like PackageName_FOUND if requirements has been satisfied. An absence of dedicated config file confuses user project as necessary variables are not set.
* Fix a precision bug of valueToString, prevent to give an error result on input of wanted precision 0 and a double value which end of zero before decimal point ,such as 1230.01,12300.1;
Add test cases for double valueToString with precision 0;
* Delete a test case with platform differences in the previous commit
* Fix clang-format.
* Fix clang-format!
Co-authored-by: lilei <dlilei@126.com>
* ENH: Prevent cmake in source builds
Building directly inside the root of the source tree
can cause problems where the build intermediate files
overwrite or conflict with the intended source code
files.
This modification identifies this problem and
issues failure messages and suggestions to over
come the problem with more robust build suggestion.
Co-authored-by: Jordan Bayles <jophba@chromium.org>
This lets us simplify linux a little.
However, we still want to test cmake, so there is only so much we
can simplify.
For OSX, we still need `clang-format` from homebrew.
* Add PYTHONUSERBASE/bin to PATH for linux
* BUILD_TYPE corresponds to Release/Debug
but LIB_TYPE corresponds to shared/static.
* Add support to build shared, static and object lib at the same time.
This patch adds an explicit ctor with a std::nullptr_t argument, that is `delete`-d. This keeps Json::Value from exposing a coding error when automatically promoted to a const char* type.
* avoid isprint
`std::isprint` is locale-specific and the JSON-spec is not.
In particular, isprint('\t') is true in Windows CP1252.
Has bitten others, e.g. https://github.com/laurikari/tre/issues/64Fixes#1187
* semicolon (rookie mistake!)
* Windows tab escape testing with custom locale (#1190)
Co-authored-by: Nikolay Baklicharov <thestorm.nik@gmail.com>
* avoid isprint
`std::isprint` is locale-specific and the JSON-spec is not.
In particular, isprint('\t') is true in Windows CP1252.
Has bitten others, e.g. https://github.com/laurikari/tre/issues/64Fixes#1187
* semicolon (rookie mistake!)
This patch fixes a fuzzing bug by resolving a bad fallthrough in the
setComment logic.
The result is that we get a proper error instead of an assert, making
the library friendlier to use and less likely to cause issue for
consumers.
See related Chromium project bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=989851
Issue: 1182
* [clang-tidy] change functions to static
Found with readability-convert-member-functions-to-static
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* optimize JsonWriter::validate #1171
* do the same for json_reader
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* use std::any_of
Also simplified two loops.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Co-authored-by: Billy Donahue <billy.donahue@gmail.com>
Commit aebc7fa added version checks for CMake compatibility. In reality,
only the add_compile_definitions need the check - add_compile_options
itself has been supported since 3.0. Tested and confirmed built
successfully with CMake 3.8.0.
Since CMake has subdirectory variable scope, unilaterally set the
CMAKE_CXX_STANDARD variable to use C++11. This covers cases with the
library being included externally, both in cases of only C++98 being
specified, as well as later versions being specified (since the
CXX_STANDARD itself isn't a library dependency, only the PUBLIC
target_compile_features on jsoncpp_lib). The previous direct check for
C++98 is handled by requiring C++11 on this library; should the
compiler being used not support C++11 then CMake will issue an error.
As of CMake 3.0 with CMP0042, MACOSX_RPATH is enabled by default.
Since the validated version used by jsoncpp is later than 3.0,
this is already covered.
The more general CMake way to handle library suffixing is to set
CMAKE_<CONFIG>_POSTFIX, so setting the Debug output suffix name should
be more correctly done by the caller or CMake configurer by setting
the desired value in CMAKE_DEBUG_POSTFIX.
A recent PR broken the JsonChecker tests by adding support for trailing
commas. This didn't end up breaking the build, because those tests
aren't run, except locally and only using CMake.
This patch fixes the tests by adding exclusions for trailing comma
tests, as well as updates Meson to run these tests as part of `ninja
test`.
See issue #1102.
* [clang-tidy] remove redundant string initialization
Found with readability-redundant-string-init
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* [clang-tidy] switch to raw strings
Easier to read.
Found with modernize-raw-string-literal
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* [clang-tidy] fix performance issues
Found with performance*
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* fix extra comma warnings
Found with clang's -Wextra-semi-stmt
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* remove JSONCPP_OP_EXPLICIT
This codebase in C++11. No need for compatibility with C++98.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* remove JSONCPP_NOEXCEPT
This codebase is C++11 now. No need for this macro.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
For Apple clang-800.0.42.1, which was released with Xcode 8 in
September 2016, the '=delete' on the 'is' and 'as' methods causes
the following errors for value.h:
inline declaration of 'as<bool>' follows non-inline definition
inline declaration of 'is<bool>' follows non-inline definition
etcetera for the other specializations of 'is' and 'as'. The same
problem also occurs for clang-3.8 but not clang-3.9 or later.
* [clang-tidy] Do not use else after return
Found with readability-else-after-return
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* [clang-tidy] Convert several loops to be range based
Found with modernize-loop-convert
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* [clang-tidy] Replace deprecated C headers
Found with modernize-deprecated-headers
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* [clang-tidy] Use auto where applicable
Found with modernize-use-auto
Signed-off-by: Rosen Penev <rosenp@gmail.com>
* .clang-tidy: Add these checks
* Modernize meson.build
* Make tests optional
* Use `files()` for quick sanity checks
* Bump version to 1.9.3
* Bump SOVERSION, as some functions were removed
and structs were changed, as determined by
libabigail.
This bug is only affects platforms where `char` is unsigned.
When char is a signed type, values >= 0x80 are also considered < 0,
and hence require escaping due to the < ' ' condition.
When char is an unsigned type, values >= 0x80 match none of the
conditions and are considered safe to emit without escaping.
This shows up as a test failure:
* Detail of EscapeSequenceTest/writeEscapeSequence test failure:
/build/source/src/test_lib_json/main.cpp(3370): expected == result
Expected: '["\"","\\","\b","\f","\n","\r","\t","\u0278","\ud852\udf62"]
'
Actual : '["\"","\\","\b","\f","\n","\r","\t","ɸ","𤭢"]
'
* Add option JSONCPP_WITH_EXAMPLE
Allows to conditionally build examples as
it has been done for tests. Useful for packaging.
* Do not build example by default
