Merge branch 'develop' into bon8

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

docs/mkdocs/docs/api/basic_json/to_bson.md

@@ -46,9 +46,8 @@ Strong guarantee: if an exception is thrown, there are no changes in the JSON va
 
 ## Complexity
 
-Proportional to the size of the JSON value `j` multiplied by its maximum nesting
-depth, `O(n × d)`. BSON length prefixes are computed recursively before nested
-values are written.
+Linear in the size of the JSON value `j`. The length prefixes of all nested documents and arrays are computed in one
+pass before anything is written.
 
 ## Examples
 
@@ -78,3 +77,4 @@ values are written.
 ## Version history
 
 - Added in version 3.4.0.
+- Linear in the size of `j`, and no longer limited by the call stack for deeply nested values, since version 3.13.0.

docs/mkdocs/docs/api/macros/json_strict_nul_handling.md

@@ -65,6 +65,12 @@ The default value is `0` (disabled — existing behavior is preserved).
     for CBOR or MessagePack, are never affected by this trimming; their full extent - including a genuine trailing
     `0x00` - is always preserved, in both states of this macro.
 
+!!! note "ABI compatibility"
+
+    The value of this macro is encoded in the [namespace](../../features/namespace.md) (tag `_snul`), resulting in
+    distinct symbol names. Translation units compiled with and without it can therefore be linked into the same program
+    without One Definition Rule (ODR) violations, but they cannot exchange instances of library types.
+
 !!! tip "Workaround without the macro"
 
     To reject a NUL byte without enabling this macro, trim your input yourself before calling `parse()`:

docs/mkdocs/docs/api/macros/nlohmann_define_derived_type.md

@@ -57,7 +57,8 @@ Summary:
 :   name of the base type (class, struct) `type` is derived from
 
 `member` (in)
-:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
+:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated
+    list, which may also be empty
 
 ## Default definition
 
@@ -127,6 +128,20 @@ void to_json(BasicJsonType& j, const B& b) {
     - Macros 4, 5, and 6 have the same prerequisites of [NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE](nlohmann_define_type_non_intrusive.md).
     - Serialization/deserialization of base types must be defined.
 
+!!! info "Derived types without own members"
+
+    The member list may be empty. The macro then generates a `to_json`/`from_json` pair that only delegates to
+    the base type, so `type` serializes exactly like `base_type`:
+
+    ```cpp
+    struct derived : base
+    {
+        NLOHMANN_DEFINE_DERIVED_TYPE_INTRUSIVE(derived, base)
+    };
+    ```
+
+    The `WITH_NAMES` variants do not support this.
+
 !!! warning "Implementation limits"
 
     See Implementation limits for [NLOHMANN_DEFINE_TYPE_INTRUSIVE](nlohmann_define_type_intrusive.md) and

docs/mkdocs/docs/api/macros/nlohmann_define_type_intrusive.md

@@ -33,7 +33,8 @@ Summary:
 :   name of the type (class, struct) to serialize/deserialize
 
 `member` (in)
-:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
+:   name of the member variable to serialize/deserialize; up to 63 members can be given as a comma-separated
+    list, which may also be empty
 
 ## Default definition
 
@@ -58,6 +59,20 @@ See the examples below for the concrete generated code.
 
 [GetNonDefNonCopy]: ../../features/arbitrary_types.md#how-can-i-use-get-for-non-default-constructiblenon-copyable-types
 
+!!! info "Types without members"
+
+    The member list may be empty. The macro then generates a `to_json` that produces an empty JSON object
+    `#!json {}`, and a `from_json` that reads no members:
+
+    ```cpp
+    struct marker
+    {
+        NLOHMANN_DEFINE_TYPE_INTRUSIVE(marker)
+    };
+    ```
+
+    The `WITH_NAMES` variants do not support this.
+
 !!! warning "Implementation limits"
 
     - The current implementation is limited to at most 63 member variables. If you want to serialize/deserialize types

docs/mkdocs/docs/api/macros/nlohmann_define_type_non_intrusive.md

@@ -33,7 +33,8 @@ Summary:
 :   name of the type (class, struct) to serialize/deserialize
 
 `member` (in)
-:   name of the (public) member variable to serialize/deserialize; up to 63 members can be given as a comma-separated list
+:   name of the (public) member variable to serialize/deserialize; up to 63 members can be given as a
+    comma-separated list, which may also be empty
 
 ## Default definition
 
@@ -59,6 +60,18 @@ See the examples below for the concrete generated code.
 
 [GetNonDefNonCopy]: ../../features/arbitrary_types.md#how-can-i-use-get-for-non-default-constructiblenon-copyable-types
 
+!!! info "Types without members"
+
+    The member list may be empty. The macro then generates a `to_json` that produces an empty JSON object
+    `#!json {}`, and a `from_json` that reads no members:
+
+    ```cpp
+    struct marker {};
+    NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(marker)
+    ```
+
+    The `WITH_NAMES` variants do not support this.
+
 !!! warning "Implementation limits"
 
     - The current implementation is limited to at most 63 member variables. If you want to serialize/deserialize types

docs/mkdocs/docs/community/assurance_case.md

@@ -43,8 +43,8 @@ that an attacker controls, passed to [`parse`](../api/basic_json/parse.md), [`ac
   user code. The destructor does not recurse, so destroying a deeply nested value does not exhaust the stack.
 - **Bounded recursion.** The JSON parser and the binary readers keep their state in explicit stacks instead of
   recursing per nesting level. Operations that walk a value, such as [`dump`](../api/basic_json/dump.md), copying,
-  hashing, and [`merge_patch`](../api/basic_json/merge_patch.md), recurse only up to a fixed depth and continue with an
-  explicit stack below it. Some operations, such as comparison, [`diff`](../api/basic_json/diff.md),
+  comparison, hashing, and [`merge_patch`](../api/basic_json/merge_patch.md), recurse only up to a fixed depth and
+  continue with an explicit stack below it. Some operations, such as [`diff`](../api/basic_json/diff.md),
   [`flatten`](../api/basic_json/flatten.md), and the binary writers, still recurse once per nesting level; work on them
   is in progress. Applications that process untrusted input can limit its nesting depth with a
   [parser callback](../features/parsing/parser_callbacks.md).

docs/mkdocs/docs/community/governance.md

@@ -91,6 +91,31 @@ activities include (but are not limited to):
 Users who continue to engage with the project and its community will often find themselves becoming more and more
 involved. Such users may then go on to become contributors, as described above.
 
+## Access to project resources
+
+The project's resources are the [GitHub repository](https://github.com/nlohmann/json) with its settings, CI workflows
+and secrets, and the documentation at [json.nlohmann.me](https://json.nlohmann.me), which is built and deployed from
+the repository. Currently, the project lead is the only person with write or admin access to them.
+
+### Granting access
+
+Write or admin access is only granted by the project lead, and only to a contributor whose track record in the project
+the project lead has reviewed first. The role is assigned manually and is the lowest one that is needed for the task.
+Access is removed when it is no longer needed. GitHub requires two-factor authentication for everyone who can modify the
+repository.
+
+### Secrets
+
+The CI workflows mostly use the token that GitHub creates for each workflow run. It is read-only by default, and each
+workflow requests only the additional permissions it needs. The few other credentials, such as the token for
+[Semgrep](https://semgrep.dev), are stored as encrypted GitHub Actions secrets:
+
+- Only people with admin access can create, change, or delete them. Their values cannot be read back, not even by
+  admins.
+- They are not passed to workflows that run for pull requests from forks.
+- They must never be committed to the repository or printed in logs.
+- They are rotated whenever someone with admin access leaves the project, and immediately if a leak is suspected.
+
 ## Support
 
 All participants in the community are encouraged to provide support for new users within the project management

docs/mkdocs/docs/community/quality_assurance.md

@@ -200,6 +200,25 @@ Note: Some modern features (like C++20 ranges or filesystem support) may be disa
 - [x] The test suite is executed with [Sanitizers](https://github.com/google/sanitizers) (address sanitizer, undefined
   behavior sanitizer, integer overflow detection, nullability violations).
 
+## Dependencies
+
+!!! success "Requirement: No vulnerable dependencies"
+
+    The library has no dependencies besides the C++ standard library. The tools used to build, test, and document it
+    are kept free of known vulnerabilities.
+
+- [x] GitHub Actions are pinned to a commit hash, and the Python packages used by the documentation and the tools are
+  pinned to exact versions.
+- [x] [Dependabot](https://docs.github.com/en/code-security/dependabot) checks these dependencies daily and proposes
+  updates as pull requests.
+- [x] Every pull request is checked with the
+  [dependency review action](https://github.com/actions/dependency-review-action). A pull request that adds a
+  dependency with a known vulnerability of any severity fails this check and is not merged.
+- [x] Vulnerability alerts for dependencies are fixed or dismissed with a documented reason before the next release.
+  No release is made while such an alert is open.
+- [x] Third-party code included in the repository for testing, such as [doctest](https://github.com/doctest/doctest),
+  is updated manually.
+
 ## Style check
 
 !!! success "Requirement: Common code style"

docs/mkdocs/docs/features/arbitrary_types.md

@@ -215,6 +215,24 @@ For _derived_ classes and structs, use the following macros
     nlohmann::ordered_json j = p; // keys appear in declaration order: name, address, age
     ```
 
+!!! note "Zero-member types"
+
+    All 12 `NLOHMANN_DEFINE_TYPE_*`/`NLOHMANN_DEFINE_DERIVED_TYPE_*` macros (excluding the `WITH_NAMES` variants)
+    also accept types with no member variables to serialize, producing/accepting an empty JSON object `{}`
+    (or, for the derived-type macros, just the base class's own JSON representation):
+
+    ```cpp
+    namespace ns {
+        struct marker {
+            bool operator==(const marker&) const { return true; }
+            NLOHMANN_DEFINE_TYPE_INTRUSIVE(marker)
+        };
+    }
+
+    ns::marker m{};
+    nlohmann::json j = m; // {}
+    ```
+
 !!! note "No macro for non-default-constructible types"
 
     There is currently no `NLOHMANN_DEFINE_TYPE_*`-style macro for types that are not

docs/mkdocs/docs/features/binary_formats/bson.md

@@ -109,6 +109,15 @@ The library maps BSON record types to JSON value types as follows:
     If BSON input must be validated for strict specification compliance, validate it separately before passing it to
     `from_bson()`.
 
+!!! warning "UTF-8 validation of string values"
+
+    The BSON specification requires `string` values (type `0x02`) to be valid UTF-8. This library validates the
+    bytes of every such string at decode time and rejects ill-formed UTF-8 with a
+    [`parse_error.113`](../../home/exceptions.md#jsonexceptionparse_error113) exception (or, with `allow_exceptions`
+    set to `false`, a discarded value), rather than only failing later when the resulting value is dumped. Element
+    (key) names and `binary` values (type `0x05`) are unaffected and are never validated, since they are read
+    byte-by-byte as a C string, or are not required to hold text, respectively.
+
 ??? example
 
     ```cpp

docs/mkdocs/docs/features/binary_formats/cbor.md

@@ -176,6 +176,16 @@ The library maps CBOR types to JSON value types as follows:
 
     CBOR allows map keys of any type, whereas JSON only allows strings as keys in object values. Therefore, CBOR maps with keys other than UTF-8 strings are rejected.
 
+!!! warning "UTF-8 validation of text strings"
+
+    [RFC 8949, Section 3.1](https://www.rfc-editor.org/rfc/rfc8949.html#section-3.1) requires CBOR text strings
+    (major type 3) to be valid UTF-8. This library validates the bytes of every text string (object keys included) at
+    decode time and rejects ill-formed UTF-8 with a
+    [`parse_error.113`](../../home/exceptions.md#jsonexceptionparse_error113) exception (or, with
+    `allow_exceptions` set to `false`, a discarded value), rather than only failing later when the resulting value is
+    dumped. Byte strings (major type 2) are unaffected and are never validated, since they are not required to hold
+    text.
+
 !!! warning "Tagged items"
 
     Tagged items (0xC0..0xDB) will throw a parse error by default. They can be ignored by passing `cbor_tag_handler_t::ignore` to function `from_cbor`, in which case the tag is skipped and the enclosed data item is parsed on its own. They can be stored by passing `cbor_tag_handler_t::store` to function `from_cbor`. Note that no tag is ever interpreted: for instance, a text string tagged with tag 0 (date/time) stays a string.

docs/mkdocs/docs/features/binary_formats/messagepack.md

@@ -136,6 +136,14 @@ The library maps MessagePack types to JSON value types as follows:
 
     Any MessagePack output created by `to_msgpack` can be successfully parsed by `from_msgpack`.
 
+!!! warning "UTF-8 validation of string values"
+
+    The MessagePack specification requires `str` values (`fixstr`, `str 8`, `str 16`, `str 32`) to be valid UTF-8.
+    This library validates the bytes of every such string (object keys included) at decode time and rejects
+    ill-formed UTF-8 with a [`parse_error.113`](../../home/exceptions.md#jsonexceptionparse_error113) exception (or,
+    with `allow_exceptions` set to `false`, a discarded value), rather than only failing later when the resulting
+    value is dumped. `bin`/`ext`/`fixext` values are unaffected and are never validated, since they are not required
+    to hold text.
 
 ??? example
 

docs/mkdocs/docs/features/namespace.md

@@ -19,6 +19,7 @@ The complete default namespace name is derived as follows:
     - [`JSON_BRACE_INIT_COPY_SEMANTICS`](../api/macros/json_brace_init_copy_semantics.md) defined non-zero appends
       `_bics`.
     - [`JSON_PRECISE_STREAM_POSITION`](../api/macros/json_precise_stream_position.md) defined non-zero appends `_psp`.
+    - [`JSON_STRICT_NUL_HANDLING`](../api/macros/json_strict_nul_handling.md) defined non-zero appends `_snul`.
 - The inline namespace ends with the suffix `_v` followed by the 3 components of the version number separated by
   underscores. To omit the version component, see [Disabling the version component](#disabling-the-version-component)
   below.

docs/mkdocs/docs/features/types/template_parameters.md

@@ -562,7 +562,11 @@ binary32 or binary64 field and have no encoding for `#!cpp long double`.
 ## `AllocatorType`
 
 `AllocatorType` is instantiated with **one** argument, for each of `object_t`, `array_t`, `string_t`, `binary_t`,
-`basic_json`, and `#!cpp std::pair<const StringType, basic_json>`.
+`basic_json`, `#!cpp std::pair<const StringType, basic_json>`, and `#!cpp std::pair<StringType, basic_json>`.
+
+`AllocatorType` is not the only allocator a `basic_json` uses. It allocates the JSON values themselves, but most
+temporary storage is allocated with `#!cpp std::allocator`. This includes the parser's stacks and the stacks that
+process deeply nested values without recursion.
 
 ### Always required
 

docs/mkdocs/docs/home/design_goals.md

@@ -6,7 +6,7 @@ There are myriads of [JSON](https://json.org) libraries out there, and each may
 
 - **Trivial integration**. Our whole code consists of a single header file [`json.hpp`](https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp). That's it. No library, no subproject, no dependencies, no complex build system. The class is written in vanilla C++11. All in all, everything should require no adjustment of your compiler flags or project settings.
 
-- **Serious testing**. Our class is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](http://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [Core Infrastructure Initiative (CII) best practices](https://bestpractices.coreinfrastructure.org/projects/289).
+- **Serious testing**. Our class is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](http://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [OpenSSF Best Practices](https://www.bestpractices.dev/projects/289).
 
 Other aspects were not so important to us:
 

docs/mkdocs/docs/home/exceptions.md

@@ -340,7 +340,8 @@ An unexpected byte was read in a [binary format](../features/binary_formats/inde
 ### json.exception.parse_error.113
 
 A string could not be read from a [binary format](../features/binary_formats/index.md): either a value that is not a
-string was read where one was required (for instance as a map key), or the string's length specification is invalid.
+string was read where one was required (for instance as a map key), the string's length specification is invalid, or
+the string's bytes are not valid UTF-8.
 
 !!! failure "Example messages"
 
@@ -356,6 +357,9 @@ string was read where one was required (for instance as a map key), or the strin
     ```
     [json.exception.parse_error.113] parse error at byte 3: syntax error while parsing BJData string: string length must not be negative
     ```
+    ```
+    [json.exception.parse_error.113] parse error at byte 3: syntax error while parsing CBOR string: invalid string: ill-formed UTF-8 byte
+    ```
 
 ### json.exception.parse_error.114