11// !!! DO NOT EDIT - THIS IS AN AUTO-GENERATED FILE !!!
2- // Created by amalgamation.sh on 2024-09-19T00:48:39Z
2+ // Created by amalgamation.sh on 2024-09-19T15:00:26Z
33
44/*
55 * The CRoaring project is under a dual license (Apache/MIT).
5959// /include/roaring/roaring_version.h automatically generated by release.py, do not change by hand
6060#ifndef ROARING_INCLUDE_ROARING_VERSION
6161#define ROARING_INCLUDE_ROARING_VERSION
62- #define ROARING_VERSION " 4.1.3 "
62+ #define ROARING_VERSION " 4.1.4 "
6363enum {
6464 ROARING_VERSION_MAJOR = 4 ,
6565 ROARING_VERSION_MINOR = 1 ,
66- ROARING_VERSION_REVISION = 3
66+ ROARING_VERSION_REVISION = 4
6767};
6868#endif // ROARING_INCLUDE_ROARING_VERSION
6969// clang-format on/* end file include/roaring/roaring_version.h */
@@ -1679,6 +1679,10 @@ size_t roaring_bitmap_shrink_to_fit(roaring_bitmap_t *r);
16791679 * This function is endian-sensitive. If you have a big-endian system (e.g., a
16801680 * mainframe IBM s390x), the data format is going to be big-endian and not
16811681 * compatible with little-endian systems.
1682+ *
1683+ * When serializing data to a file, we recommend that you also use
1684+ * checksums so that, at deserialization, you can be confident
1685+ * that you are recovering the correct data.
16821686 */
16831687size_t roaring_bitmap_serialize (const roaring_bitmap_t *r, char *buf);
16841688
@@ -1742,7 +1746,10 @@ roaring_bitmap_t *roaring_bitmap_portable_deserialize(const char *buf);
17421746 * https://github.com/RoaringBitmap/RoaringFormatSpec
17431747 *
17441748 * The function itself is safe in the sense that it will not cause buffer
1745- * overflows. However, for correct operations, it is assumed that the bitmap
1749+ * overflows: it will not read beyond the scope of the provided buffer
1750+ * (buf,maxbytes).
1751+ *
1752+ * However, for correct operations, it is assumed that the bitmap
17461753 * read was once serialized from a valid bitmap (i.e., it follows the format
17471754 * specification). If you provided an incorrect input (garbage), then the bitmap
17481755 * read may not be in a valid state and following operations may not lead to
@@ -1752,8 +1759,10 @@ roaring_bitmap_t *roaring_bitmap_portable_deserialize(const char *buf);
17521759 * but not for random inputs.
17531760 *
17541761 * You may use roaring_bitmap_internal_validate to check the validity of the
1755- * bitmap prior to using it. You may also use other strategies to check for
1756- * corrupted inputs (e.g., checksums).
1762+ * bitmap prior to using it.
1763+ *
1764+ * We recommend that you use checksums to check that serialized data corresponds
1765+ * to a serialized bitmap.
17571766 *
17581767 * This function is endian-sensitive. If you have a big-endian system (e.g., a
17591768 * mainframe IBM s390x), the data format is going to be big-endian and not
@@ -1815,6 +1824,10 @@ size_t roaring_bitmap_portable_size_in_bytes(const roaring_bitmap_t *r);
18151824 * This function is endian-sensitive. If you have a big-endian system (e.g., a
18161825 * mainframe IBM s390x), the data format is going to be big-endian and not
18171826 * compatible with little-endian systems.
1827+ *
1828+ * When serializing data to a file, we recommend that you also use
1829+ * checksums so that, at deserialization, you can be confident
1830+ * that you are recovering the correct data.
18181831 */
18191832size_t roaring_bitmap_portable_serialize (const roaring_bitmap_t *r, char *buf);
18201833
@@ -1849,6 +1862,10 @@ size_t roaring_bitmap_frozen_size_in_bytes(const roaring_bitmap_t *r);
18491862 * This function is endian-sensitive. If you have a big-endian system (e.g., a
18501863 * mainframe IBM s390x), the data format is going to be big-endian and not
18511864 * compatible with little-endian systems.
1865+ *
1866+ * When serializing data to a file, we recommend that you also use
1867+ * checksums so that, at deserialization, you can be confident
1868+ * that you are recovering the correct data.
18521869 */
18531870void roaring_bitmap_frozen_serialize (const roaring_bitmap_t *r, char *buf);
18541871
@@ -2809,6 +2826,10 @@ size_t roaring64_bitmap_portable_size_in_bytes(const roaring64_bitmap_t *r);
28092826 * This function is endian-sensitive. If you have a big-endian system (e.g., a
28102827 * mainframe IBM s390x), the data format is going to be big-endian and not
28112828 * compatible with little-endian systems.
2829+ *
2830+ * When serializing data to a file, we recommend that you also use
2831+ * checksums so that, at deserialization, you can be confident
2832+ * that you are recovering the correct data.
28122833 */
28132834size_t roaring64_bitmap_portable_serialize (const roaring64_bitmap_t *r,
28142835 char *buf);
@@ -2823,14 +2844,17 @@ size_t roaring64_bitmap_portable_deserialize_size(const char *buf,
28232844 size_t maxbytes);
28242845
28252846/* *
2826- * Read a bitmap from a serialized buffer safely (reading up to maxbytes).
2847+ * Read a bitmap from a serialized buffer (reading up to maxbytes).
28272848 * In case of failure, NULL is returned.
28282849 *
28292850 * This is meant to be compatible with other languages
28302851 * https://github.com/RoaringBitmap/RoaringFormatSpec#extension-for-64-bit-implementations
28312852 *
28322853 * The function itself is safe in the sense that it will not cause buffer
2833- * overflows. However, for correct operations, it is assumed that the bitmap
2854+ * overflows: it will not read beyond the scope of the provided buffer
2855+ * (buf,maxbytes).
2856+ *
2857+ * However, for correct operations, it is assumed that the bitmap
28342858 * read was once serialized from a valid bitmap (i.e., it follows the format
28352859 * specification). If you provided an incorrect input (garbage), then the bitmap
28362860 * read may not be in a valid state and following operations may not lead to
@@ -2839,6 +2863,12 @@ size_t roaring64_bitmap_portable_deserialize_size(const char *buf,
28392863 * order. This is is guaranteed to happen when serializing an existing bitmap,
28402864 * but not for random inputs.
28412865 *
2866+ * You may use roaring64_bitmap_internal_validate to check the validity of the
2867+ * bitmap prior to using it.
2868+ *
2869+ * We recommend that you use checksums to check that serialized data corresponds
2870+ * to a serialized bitmap.
2871+ *
28422872 * This function is endian-sensitive. If you have a big-endian system (e.g., a
28432873 * mainframe IBM s390x), the data format is going to be big-endian and not
28442874 * compatible with little-endian systems.
0 commit comments