Go to file
Jessica Clarke 42e892d96e
Use default rather than hard-coded 8 for maximum aggregate member alignment (#1378)
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.
2022-01-12 16:27:16 -05:00
.github/ISSUE_TEMPLATE Update issue templates 2019-06-24 14:40:08 -07:00
.travis_scripts clang-format is not available by default 2021-10-28 13:38:53 -05:00
cmake Fix generation of pkg-config file with absolute includedir/libdir. (#1199) 2020-07-20 20:36:30 +08:00
devtools Remove trailing space characters (#1256) 2021-01-09 22:39:07 -06:00
doc Cleanup versioning strategy relanding (#989) (#997) 2019-08-13 22:41:43 -07:00
example minor fix for code examples (#1317) 2021-08-12 17:08:46 -04:00
include Use default rather than hard-coded 8 for maximum aggregate member alignment (#1378) 2022-01-12 16:27:16 -05:00
pkg-config Fixed pkg-config Version 2021-02-03 13:40:56 -06:00
src Fix various typos (#1350) 2021-12-14 18:04:47 -08:00
test Parse large floats as infinity (#1349) (#1353) 2021-12-14 18:00:28 -08:00
.clang-format Issue #958: Travis CI should enforce clang-format standards (#1026) 2019-10-11 11:19:00 -07:00
.clang-tidy Remove trailing space characters (#1256) 2021-01-09 22:39:07 -06:00
.gitattributes add .gitattributes 2015-08-09 16:25:36 -07:00
.gitignore Update version in dox 2021-01-10 00:18:59 -06:00
.travis.yml clang-format is not available by default 2021-10-28 13:38:53 -05:00
amalgamate.py amalgamate: add version.h and allocator.h to the forwards header 2020-04-23 23:22:10 -05:00
appveyor.yml ENH: Prevent cmake in source builds (#1091) 2020-11-06 13:35:51 -08:00
AUTHORS Update README.md and add dota17 to AUTHORS list. (#1168) 2020-04-30 18:05:17 +08:00
BUILD.bazel Add support for Bazel build system (#1275) 2021-05-05 21:03:02 -05:00
CMakeLists.txt Fix various typos (#1350) 2021-12-14 18:04:47 -08:00
CONTRIBUTING.md Fix various typos (#1350) 2021-12-14 18:04:47 -08:00
CTestConfig.cmake ENH: Refactor and enhance the CI testing infrastructure 2019-01-14 16:12:43 -06:00
dev.makefile Update version in dox 2021-01-10 00:18:59 -06:00
doxybuild.py Remove trailing space characters (#1256) 2021-01-09 22:39:07 -06:00
get_version.pl Update version in dox 2021-01-10 00:18:59 -06:00
jsoncpp-namespaced-targets.cmake - isolated namespace targets into separate file 2021-05-04 23:34:28 -05:00
jsoncppConfig.cmake.in - isolated namespace targets into separate file 2021-05-04 23:34:28 -05:00
LICENSE Remove trailing space characters (#1256) 2021-01-09 22:39:07 -06:00
meson_options.txt Meson updates (#1124) 2020-01-07 09:23:50 +08:00
meson.build Bump micro version 2021-11-03 11:39:54 -05:00
README.md Added current dir specifier for PowerShell (#1169) 2020-05-08 09:00:12 +08:00
reformat.sh Fix clang-tidy warnings (#1231) 2020-11-06 13:22:26 -08:00
version.in generate both version.h and version from CMakelists.txt 2015-03-05 18:27:39 -06:00

JsonCpp

badge badge badge Coverage Status

JSON is a lightweight data-interchange format. It can represent numbers, strings, ordered sequences of values, and collections of name/value pairs.

JsonCpp is a C++ library that allows manipulating JSON values, including serialization and deserialization to and from strings. It can also preserve existing comment in unserialization/serialization steps, making it a convenient format to store user input files.

Documentation

JsonCpp documentation is generated using Doxygen.

A note on backward-compatibility

  • 1.y.z is built with C++11.
  • 0.y.z can be used with older compilers.
  • 00.11.z can be used both in old and new compilers.
  • Major versions maintain binary-compatibility.

Special note

The branch 00.11.zis a new branch, its major version number 00 is to show that it is different from 0.y.z and 1.y.z, the main purpose of this branch is to make a balance between the other two branches. Thus, users can use some new features in this new branch that introduced in 1.y.z, but can hardly applied into 0.y.z.

Using JsonCpp in your project

The vcpkg dependency manager

You can download and install JsonCpp using the vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install jsoncpp

The JsonCpp port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Amalgamated source

https://github.com/open-source-parsers/jsoncpp/wiki/Amalgamated-(Possibly-outdated)

The Meson Build System

If you are using the Meson Build System, then you can get a wrap file by downloading it from Meson WrapDB, or simply use meson wrap install jsoncpp.

Other ways

If you have trouble, see the Wiki, or post a question as an Issue.

License

See the LICENSE file for details. In summary, JsonCpp is licensed under the MIT license, or public domain if desired and recognized in your jurisdiction.