Update code from the upstream repo to v1.9.5 #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Implement Value::demand()
This patch fixes the JSON_USE_EXCEPTION flag. Currently, due to the throwRuntimeError and throwLogicError methods implemented in json_value, even if JSON_USE_EXCEPTION is set to 0 jsoncpp will still throw. This breaks integration into projects with -fno-exceptions set, such as Chromium.
…-declarations Add missing classes to forwards.h
Currently, we have a build type warning due to listing a requirement for meson build version that doesn't implement features we use in our build file. The minimum meson build version required is actually 0.50.0, so this PR updates our meson.build file to depend on 0.50.0.
Separate contributing guidelines into their own separate documentation.
Added style information.
Clang format hasn't been run on some recent checkins. This patch updates the repository with clang format properly run on all files.
Update meson build requirement
Run clang format
…config_version added cmake config version file for proper cmake delivery
…clean cmake cleanup
This PR updates the Travis and Appveyor configs to use more recent toolchain versions, allowing for better C++11 compliance.
(creating merge-commit late, after accidental "rebase-and-merge")
Co-authored-by: Christopher Dunn <cdunn2001@gmail.com>
The minimum version for the project is CMake 3.8.0, so there's no point in keeping legacy code for pre-3.0 or pre-2.8 CMake.
…BUILD_SHARED_LIBS is ON
…ependent_code Fix POSITION_INDEPENDENT_CODE
…drop-deprecation-warnings Drop compile-time deprecation warning
…e-parsers#1353) 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>
Found via `codespell -q 3 -L alue,alse` Co-authored-by: Christopher Dunn <cdunn2001@gmail.com> Co-authored-by: Jordan Bayles <jophba@chromium.org>
…gnment (open-source-parsers#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.
mike-malburg
changed the title
mike-malburg
force-pushed
the
update/upstream/1.9.5
branch
from
e9d51c4 to
f147eb0
Compare
dchengTSC
approved these changes
Feb 21, 2023
dchengTSC
approved these changes
Feb 22, 2023
mike-malburg
force-pushed
the
update/upstream/1.9.5
branch
from
fd89879 to
fc6ce76
Compare
Applying Stephen Wagner's fix from this commit to JsonCpp 1.9.5: c36b636
bberton
approved these changes
Feb 23, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
We were based off of 1.4.0 (2/11/2015). This updates us to be based off of the latest release, 1.9.5 (11/3/2021).
The purpose of this is to update to a more secure version of JsonCPP.
JsonCPP self-reported security issues (fixed in 1.9.5):