vendor/libcbor/0.12.0

16 files changed, 139 insertions, 71 deletions

diff --git a/doc/source/api.rst b/doc/source/api.rst
index 75b0541cb94e..616f12103124 100644
--- a/doc/source/api.rst
+++ b/doc/source/api.rst
@@ -30,12 +30,12 @@ The API is designed to allow both very tight control & flexibility and general c
    api/encoding
    api/streaming_decoding
    api/streaming_encoding
-   api/type_0_1
-   api/type_2
-   api/type_3
-   api/type_4
-   api/type_5
-   api/type_6
-   api/type_7
+   api/type_0_1_integers
+   api/type_2_byte_strings
+   api/type_3_strings
+   api/type_4_arrays
+   api/type_5_maps
+   api/type_6_tags
+   api/type_7_floats_ctrls
 
 .. [#] http://softwareengineering.vazexqi.com/files/pattern.html
diff --git a/doc/source/api/streaming_encoding.rst b/doc/source/api/streaming_encoding.rst
index 25100da9b5e0..ebb2f72057af 100644
--- a/doc/source/api/streaming_encoding.rst
+++ b/doc/source/api/streaming_encoding.rst
@@ -7,7 +7,7 @@ exposes a low-level encoding API to encode CBOR objects on the fly. Unlike
 strings, etc.) instead of :type:`cbor_item_t`. The client is responsible for
 constructing the compound types correctly (e.g. terminating arrays).
 
-Streaming encoding is typically used to create an streaming (indefinite length) CBOR :doc:`strings <type_2>`, :doc:`byte strings <type_3>`, :doc:`arrays <type_4>`, and :doc:`maps <type_5>`. Complete example: `examples/streaming_array.c <https://github.com/PJK/libcbor/blob/master/examples/streaming_array.c>`_
+Streaming encoding is typically used to create an streaming (indefinite length) CBOR :doc:`strings <type_2_byte_strings>`, :doc:`byte strings <type_3_strings>`, :doc:`arrays <type_4_arrays>`, and :doc:`maps <type_5_maps>`. Complete example: `examples/streaming_array.c <https://github.com/PJK/libcbor/blob/master/examples/streaming_array.c>`_
 
 .. doxygenfunction:: cbor_encode_uint8
 
diff --git a/doc/source/api/type_0_1.rst b/doc/source/api/type_0_1_integers.rst
index 4fc851dd1ed1..4fc851dd1ed1 100644
--- a/doc/source/api/type_0_1.rst
+++ b/doc/source/api/type_0_1_integers.rst
diff --git a/doc/source/api/type_2.rst b/doc/source/api/type_2_byte_strings.rst
index ff9369a90d67..d0644fffb137 100644
--- a/doc/source/api/type_2.rst
+++ b/doc/source/api/type_2_byte_strings.rst
@@ -1,7 +1,7 @@
 Type 2 – Byte strings
 =============================
 
-CBOR byte strings are just (ordered) series of bytes without further interpretation (unless there is a :doc:`tag <type_6>`). Byte string's length may or may not be known during encoding. These two kinds of byte strings can be distinguished using :func:`cbor_bytestring_is_definite` and :func:`cbor_bytestring_is_indefinite` respectively.
+CBOR byte strings are just (ordered) series of bytes without further interpretation (unless there is a :doc:`tag <type_6_tags>`). Byte string's length may or may not be known during encoding. These two kinds of byte strings can be distinguished using :func:`cbor_bytestring_is_definite` and :func:`cbor_bytestring_is_indefinite` respectively.
 
 In case a byte string is indefinite, it is encoded as a series of definite byte strings. These are called "chunks". For example, the encoded item
 
diff --git a/doc/source/api/type_3.rst b/doc/source/api/type_3_strings.rst
index be06fc176566..847c474b0417 100644
--- a/doc/source/api/type_3.rst
+++ b/doc/source/api/type_3_strings.rst
@@ -1,7 +1,7 @@
 Type 3 – UTF-8 strings 
 =============================
 
-CBOR strings have the same structure as :doc:`type_2`.
+CBOR strings have the same structure as :doc:`type_2_byte_strings`.
 
 ==================================  ======================================================
 Corresponding :type:`cbor_type`     ``CBOR_TYPE_STRING``
diff --git a/doc/source/api/type_4.rst b/doc/source/api/type_4_arrays.rst
index a76202f4a0fd..2fa615df0eb4 100644
--- a/doc/source/api/type_4.rst
+++ b/doc/source/api/type_4_arrays.rst
@@ -1,7 +1,7 @@
 Type 4 – Arrays
 =============================
 
-CBOR arrays, just like :doc:`byte strings <type_2>` and :doc:`strings <type_3>`, can be encoded either as definite, or as indefinite.
+CBOR arrays, just like :doc:`byte strings <type_2_byte_strings>` and :doc:`strings <type_3_strings>`, can be encoded either as definite, or as indefinite.
 Definite arrays have a fixed size which is stored in the header, whereas indefinite arrays do not and are terminated by a special "break" byte instead.
 
 Arrays are explicitly created or decoded as definite or indefinite and will be encoded using the corresponding wire representation, regardless of whether the actual size is known at the time of encoding.
diff --git a/doc/source/api/type_5.rst b/doc/source/api/type_5_maps.rst
index 7f7be273aba9..7f7be273aba9 100644
--- a/doc/source/api/type_5.rst
+++ b/doc/source/api/type_5_maps.rst
diff --git a/doc/source/api/type_6.rst b/doc/source/api/type_6_tags.rst
index e98457ceae2a..1ee5f6949a2e 100644
--- a/doc/source/api/type_6.rst
+++ b/doc/source/api/type_6_tags.rst
@@ -5,7 +5,12 @@ Tag are additional metadata that can be used to extend or specialize the meaning
 
 For example, one might tag an array of numbers to communicate that it should be interpreted as a vector.
 
-Please consult the official `IANA repository of CBOR tags <https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml>`_ before inventing new ones.
+Please consult the official `IANA repository of CBOR tags <https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml>`_ for known registered values.
+
+Please note that libcbor does *not* understand the semantics of tags and will
+process all `well-formed <https://datatracker.ietf.org/doc/html/rfc8949#name-terminology>`_
+tags regardless of whether they are valid with respect to the data they are
+applied to.
 
 ==================================  ======================================================
 Corresponding :type:`cbor_type`     ``CBOR_TYPE_TAG``
diff --git a/doc/source/api/type_7.rst b/doc/source/api/type_7_floats_ctrls.rst
index b105402a08b2..d893fe37cb7b 100644
--- a/doc/source/api/type_7.rst
+++ b/doc/source/api/type_7_floats_ctrls.rst
@@ -60,9 +60,16 @@ Manipulating existing items
 .. doxygenfunction:: cbor_set_float8
 
 
-.. _api_type_7_hard_floats:
+.. _api_type_7_floats_ctrls_half_floats:
 
 Half floats
 ~~~~~~~~~~~~
 CBOR supports two `bytes wide ("half-precision") <https://en.wikipedia.org/wiki/Half-precision_floating-point_format>`_
 floats which are not supported by the C language. *libcbor* represents them using `float <https://en.cppreference.com/w/c/language/type>` values throughout the API. Encoding will be performed by :func:`cbor_encode_half`, which will handle any values that cannot be represented as a half-float.
+
+Signaling NaNs
+~~~~~~~~~~~~~~~~
+
+`Signaling NaNs <https://en.wikipedia.org/wiki/NaN#Signaling_NaN)>`_ are always encoded as a standard, "quiet" NaN.
+
+The reason for this simplification is that standard C does not offer a way to handle the signaling payload without assumptions about the host architecture. See https://github.com/PJK/libcbor/issues/336 for more context.
diff --git a/doc/source/conf.py b/doc/source/conf.py
index 0eee7103bb5a..4574669505e8 100644
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -77,8 +77,8 @@ copyright = '2014 - 2020, Pavel Kalvoda'
 # built documents.
 #
 # The short X.Y version.
-version = '0.11'
-release = '0.11.0'
+version = '0.12'
+release = '0.12.0'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
diff --git a/doc/source/development.rst b/doc/source/development.rst
index 0b0ac21007ed..5471047317af 100644
--- a/doc/source/development.rst
+++ b/doc/source/development.rst
@@ -99,7 +99,8 @@ Development dependencies
 - There are some `Ruby <https://www.ruby-lang.org/en/>`_ scripts in ``misc``
 - `Valgrind <http://valgrind.org/>`_ (memory correctness & profiling)
 - `GCOV/LCOV <http://ltp.sourceforge.net/coverage/lcov.php>`_ (test coverage)
-- `clang-format`
+- `clang-format` (linter)
+- `cmakelang <https://cmake-format.readthedocs.io/en/latest/index.html>`_ (linter)
 
 
 Installing *sphinx*
diff --git a/doc/source/getting_started.rst b/doc/source/getting_started.rst
index 98c5a3956337..ee57c094458d 100644
--- a/doc/source/getting_started.rst
+++ b/doc/source/getting_started.rst
@@ -38,26 +38,65 @@ Prerequisites:
 
 A handful of configuration flags can be passed to `cmake`. The following table lists libcbor compile-time directives and several important generic flags.
 
-========================  =======================================================   ======================  =====================================================================================================================
-Option                    Meaning                                                   Default                 Possible values
-------------------------  -------------------------------------------------------   ----------------------  ---------------------------------------------------------------------------------------------------------------------
-``CMAKE_C_COMPILER``      C compiler to use                                         ``cc``                   ``gcc``, ``clang``, ``clang-3.5``, ...
-``CMAKE_INSTALL_PREFIX``  Installation prefix                                       System-dependent         ``/usr/local/lib``, ...
-``BUILD_SHARED_LIBS``     Build as a shared library                                 ``OFF``                  ``ON``, ``OFF``
-``HUGE_FUZZ``             :doc:`Fuzz test </tests>` with 8GB of data                ``OFF``                  ``ON``, ``OFF``
-``SANE_MALLOC``           Assume ``malloc`` will refuse unreasonable allocations    ``OFF``                  ``ON``, ``OFF``
-``COVERAGE``              Generate test coverage instrumentation                    ``OFF``                  ``ON``, ``OFF``
-``WITH_TESTS``            Build unit tests (see :doc:`development`)                 ``OFF``                  ``ON``, ``OFF``
-========================  =======================================================   ======================  =====================================================================================================================
+.. list-table::
+   :header-rows: 1
+
+   * - Option
+     - Meaning
+     - Default
+     - Possible values
+   * - ``CMAKE_C_COMPILER``
+     - C compiler to use
+     - ``cc``
+     - ``gcc``, ``clang``, ``clang-3.5``, ...
+   * - ``CMAKE_INSTALL_PREFIX``
+     - Installation prefix
+     - System-dependent
+     - ``/usr/local/lib``, ...
+   * - ``CMAKE_INTERPROCEDURAL_OPTIMIZATION``
+     - Enable LTO (if supported)
+     - System-dependent
+     - ``ON``, ``OFF``
+   * - ``BUILD_SHARED_LIBS``
+     - Build as a shared library
+     - ``OFF``
+     - ``ON``, ``OFF``
+   * - ``HUGE_FUZZ``
+     - :doc:`Fuzz test </tests>` with 8GB of data
+     - ``OFF``
+     - ``ON``, ``OFF``
+   * - ``SANE_MALLOC``
+     - Assume ``malloc`` will refuse unreasonable allocations
+     - ``OFF``
+     - ``ON``, ``OFF``
+   * - ``COVERAGE``
+     - Generate test coverage instrumentation
+     - ``OFF``
+     - ``ON``, ``OFF``
+   * - ``WITH_TESTS``
+     - Build unit tests (see :doc:`development`)
+     - ``OFF``
+     - ``ON``, ``OFF``
+
 
 The following configuration options will also be defined as macros [#]_ in ``<cbor/common.h>`` and can therefore be used in client code:
 
-========================  =======================================================   ======================  =====================================================================================================================
-Option                    Meaning                                                   Default                 Possible values
-------------------------  -------------------------------------------------------   ----------------------  ---------------------------------------------------------------------------------------------------------------------
-``CBOR_PRETTY_PRINTER``   Include a pretty-printing routine                         ``ON``                  ``ON``, ``OFF``
-``CBOR_BUFFER_GROWTH``    Factor for buffer growth & shrinking                       ``2``                    Decimals > 1
-========================  =======================================================   ======================  =====================================================================================================================
+.. list-table::
+   :header-rows: 1
+
+   * - Option
+     - Meaning
+     - Default
+     - Possible values
+   * - ``CBOR_PRETTY_PRINTER``
+     - Include a pretty-printing routine
+     - ``ON``
+     - ``ON``, ``OFF``
+   * - ``CBOR_BUFFER_GROWTH``
+     - Factor for buffer growth & shrinking
+     - ``2``
+     - Decimals > 1
+
 
 .. [#] ``ON`` & ``OFF`` will be translated to ``1`` and ``0`` using `cmakedefine <https://cmake.org/cmake/help/v3.2/command/configure_file.html?highlight=cmakedefine>`_.
 
diff --git a/doc/source/internal.rst b/doc/source/internal.rst
index e30cb11dffa1..07cd7cfc10c6 100644
--- a/doc/source/internal.rst
+++ b/doc/source/internal.rst
@@ -82,7 +82,7 @@ Generally speaking, data items consist of three parts:
 
     .. member:: unsigned char * data
 
-        Contains pointer to the actual data. Small, fixed size items (:doc:`api/type_0_1`, :doc:`api/type_6`, :doc:`api/type_7`) are allocated as a single memory block.
+        Contains pointer to the actual data. Small, fixed size items (:doc:`api/type_0_1_integers`, :doc:`api/type_6_tags`, :doc:`api/type_7_floats_ctrls`) are allocated as a single memory block.
 
         Consider the following snippet
 
@@ -103,7 +103,7 @@ Generally speaking, data items consist of three parts:
             |                                                                                |
             +--- item                                                                        +--- item->data
 
-        Dynamically sized types (:doc:`api/type_2`, :doc:`api/type_3`, :doc:`api/type_4`, :doc:`api/type_5`) may store handle and data in separate locations. This enables creating large items (e.g :doc:`byte strings <api/type_2>`) without :func:`realloc` or copying large blocks of memory. One simply attaches the correct pointer to the handle.
+        Dynamically sized types (:doc:`api/type_2_byte_strings`, :doc:`api/type_3_strings`, :doc:`api/type_4_arrays`, :doc:`api/type_5_maps`) may store handle and data in separate locations. This enables creating large items (e.g :doc:`byte strings <api/type_2_byte_strings>`) without :func:`realloc` or copying large blocks of memory. One simply attaches the correct pointer to the handle.
 
 
 .. type:: cbor_item_metadata
@@ -112,7 +112,7 @@ Generally speaking, data items consist of three parts:
 
     .. member:: struct _cbor_int_metadata int_metadata
 
-        Used both by both :doc:`api/type_0_1`
+        Used both by both :doc:`api/type_0_1_integers`
 
     .. member:: struct _cbor_bytestring_metadata bytestring_metadata
     .. member:: struct _cbor_string_metadata string_metadata
diff --git a/doc/source/requirements.txt b/doc/source/requirements.txt
index 502d79cc62e6..1b34e120b8b2 100644
--- a/doc/source/requirements.txt
+++ b/doc/source/requirements.txt
@@ -1,31 +1,47 @@
-alabaster==0.7.13
-Babel==2.13.1
-breathe==4.35.0
-certifi==2023.11.17
-charset-normalizer==3.3.2
+alabaster==1.0.0
+anyio==4.8.0
+babel==2.17.0
+breathe==4.36.0
+build==1.2.2.post1
+certifi==2025.1.31
+charset-normalizer==3.4.1
+click==8.1.8
 colorama==0.4.6
-docutils==0.18.1
-idna==3.4
+docutils==0.21.2
+h11==0.14.0
+idna==3.10
 imagesize==1.4.1
-importlib-metadata==6.8.0
-Jinja2==3.1.2
-livereload==2.6.3
-MarkupSafe==2.1.3
-packaging==23.2
-Pygments==2.16.1
-pyparsing==3.1.1
-pytz==2021.3
-requests==2.31.0
+importlib_metadata==8.6.1
+Jinja2==3.1.6
+livereload @ https://github.com/lepture/python-livereload/archive/master.zip#sha256=95371213cf9107242808ea6e1353b524d7c38d96e299604e651e43271263352c
+MarkupSafe==3.0.2
+packaging==24.2
+pip-tools==7.4.1
+Pygments==2.19.1
+pyparsing==3.2.1
+pyproject_hooks==1.2.0
+pytz==2025.1
+requests==2.32.3
+roman-numerals-py==3.1.0
+setuptools==75.8.2
+six==1.17.0
+sniffio==1.3.1
 snowballstemmer==2.2.0
-Sphinx==7.2.6
-sphinx-autobuild==2021.3.14
-sphinx-rtd-theme==1.3.0
-sphinxcontrib-applehelp==1.0.7
-sphinxcontrib-devhelp==1.0.5
-sphinxcontrib-htmlhelp==2.0.4
+Sphinx==8.2.3
+sphinx-autobuild==2024.10.3
+sphinx-rtd-theme==3.0.2
+sphinxcontrib-applehelp==2.0.0
+sphinxcontrib-devhelp==2.0.0
+sphinxcontrib-htmlhelp==2.1.0
+sphinxcontrib-jquery==4.1
 sphinxcontrib-jsmath==1.0.1
-sphinxcontrib-qthelp==1.0.6
-sphinxcontrib-serializinghtml==1.1.9
-tornado==6.3.3
-urllib3==2.1.0
-zipp==3.17.0
+sphinxcontrib-qthelp==2.0.0
+sphinxcontrib-serializinghtml==2.0.0
+starlette==0.46.0
+tornado==6.4.2
+urllib3==2.3.0
+uvicorn==0.34.0
+watchfiles==1.0.4
+websockets==15.0
+wheel==0.45.1
+zipp==3.21.0
diff --git a/doc/source/standard_conformance.rst b/doc/source/standard_conformance.rst
index 62965f0c4493..4f57bb4c091f 100644
--- a/doc/source/standard_conformance.rst
+++ b/doc/source/standard_conformance.rst
@@ -13,5 +13,5 @@ There is no explicit limitation of indefinite length byte strings. [#]_ *libcbor
 ---------------------------------
 As of C99 and even C11, there is no standard implementation for 2 bytes floats. *libcbor* packs them as a `float <https://en.cppreference.com/w/c/language/type>`. When encoding, *libcbor* selects the appropriate wire representation based on metadata and the actual value. This applies both to canonical and normal mode.
 
-For more information on half-float serialization, please refer to the section on :ref:`api_type_7_hard_floats`.
+For more information on half-float serialization, please refer to the section on :ref:`api_type_7_floats_ctrls_half_floats`.
 
diff --git a/doc/source/using.rst b/doc/source/using.rst
index ccb7372f23b6..c6688bbad7bd 100644
--- a/doc/source/using.rst
+++ b/doc/source/using.rst
@@ -32,19 +32,19 @@ Headers to include
 The ``cbor.h`` header includes all the symbols. If, for any reason, you don't want to include all the exported symbols,
 feel free to use just some of the ``cbor/*.h`` headers:
 
- - ``cbor/arrays.h`` - :doc:`api/type_4`
- - ``cbor/bytestrings.h`` - :doc:`api/type_2`
+ - ``cbor/arrays.h`` - :doc:`api/type_4_arrays`
+ - ``cbor/bytestrings.h`` - :doc:`api/type_2_byte_strings`
  - ``cbor/callbacks.h`` - Callbacks used for :doc:`api/streaming_decoding`
  - ``cbor/common.h`` - Common utilities - always transitively included
  - ``cbor/data.h`` - Data types definitions - always transitively included
  - ``cbor/encoding.h`` - Streaming encoders for :doc:`api/streaming_encoding`
- - ``cbor/floats_ctrls.h`` - :doc:`api/type_7`
- - ``cbor/ints.h`` - :doc:`api/type_0_1`
- - ``cbor/maps.h`` - :doc:`api/type_5`
+ - ``cbor/floats_ctrls.h`` - :doc:`api/type_7_floats_ctrls`
+ - ``cbor/ints.h`` - :doc:`api/type_0_1_integers`
+ - ``cbor/maps.h`` - :doc:`api/type_5_maps`
  - ``cbor/serialization.h`` - High level serialization such as :func:`cbor_serialize`
  - ``cbor/streaming.h`` - Home of :func:`cbor_stream_decode`
- - ``cbor/strings.h`` - :doc:`api/type_3`
- - ``cbor/tags.h`` - :doc:`api/type_6`
+ - ``cbor/strings.h`` - :doc:`api/type_3_strings`
+ - ``cbor/tags.h`` - :doc:`api/type_6_tags`
 
 
 Using libcbor