chore(croaring-sys): update to CRoaring 4.7.1

README.md

@@ -127,7 +127,7 @@ Current documentation is available at https://docs.rs/croaring/latest/croaring/
 
 ## CRoaring Version
 
-This crate uses [CRoaring version `4.7.0`](https://github.com/RoaringBitmap/CRoaring/releases/tag/v4.7.0).
+This crate uses [CRoaring version `4.7.1`](https://github.com/RoaringBitmap/CRoaring/releases/tag/v4.7.1).
 The version of this crate does not necessarily match the version of CRoaring: the major version of the crate is only
 incremented when there are breaking changes in the Rust API: It is possible (and has happened) that breaking changes
 in the CRoaring C API do not necessitate a major version bump in this crate.

croaring-sys/CRoaring/roaring.h

@@ -1,5 +1,5 @@
 // !!! DO NOT EDIT - THIS IS AN AUTO-GENERATED FILE !!!
-// Created by amalgamation.sh on 2026-05-12T23:23:45Z
+// Created by amalgamation.sh on 2026-06-11T01:03:40Z
 
 /*
  * The CRoaring project is under a dual license (Apache/MIT).
@@ -59,11 +59,11 @@
 // /include/roaring/roaring_version.h automatically generated by release.py, do not change by hand
 #ifndef ROARING_INCLUDE_ROARING_VERSION
 #define ROARING_INCLUDE_ROARING_VERSION
-#define ROARING_VERSION "4.7.0"
+#define ROARING_VERSION "4.7.1"
 enum {
     ROARING_VERSION_MAJOR = 4,
     ROARING_VERSION_MINOR = 7,
-    ROARING_VERSION_REVISION = 0
+    ROARING_VERSION_REVISION = 1
 };
 #endif // ROARING_INCLUDE_ROARING_VERSION
 // clang-format on/* end file include/roaring/roaring_version.h */
@@ -85,7 +85,7 @@ enum {
 /**
  * All macros should be prefixed with either CROARING or ROARING.
  * The library uses both ROARING_...
- * as well as CROAIRING_ as prefixes. The ROARING_ prefix is for
+ * as well as CROARING_ as prefixes. The ROARING_ prefix is for
  * macros that are provided by the build system or that are closely
  * related to the format. The header macros may also use ROARING_.
  * The CROARING_ prefix is for internal macros that a user is unlikely
@@ -134,6 +134,12 @@ enum {
 #ifdef __GLIBC__
 #include <malloc.h>  // this should never be needed but there are some reports that it is needed.
 #endif
+// alignas/alignof are keywords in C++ and in C23+, where <stdalign.h> is
+// deprecated. Only include it for C11..C17.
+#if !defined(__cplusplus) && \
+    (!defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L)
+#include <stdalign.h>
+#endif
 
 #ifdef __cplusplus
 extern "C" {  // portability definitions are in global scope, not a namespace
@@ -532,6 +538,55 @@ static inline int roaring_hamming(uint64_t x) {
 #define croaring_be64toh(x) croaring_htobe64(x)
 // End of host <-> big endian conversion.
 
+// Host <-> little-endian conversion helpers.
+//
+// The CRoaring "portable" serialization format (and the regular
+// roaring_bitmap_serialize / Roaring64Map::write formats which build on it)
+// is defined to be little-endian on the wire. Code that reads or writes
+// multi-byte integers to such buffers must convert between host and
+// little-endian byte order. On little-endian hosts these are no-ops; on
+// big-endian hosts they swap bytes.
+//
+// The "frozen" format is intentionally non-portable and uses native byte
+// order; it must not use these helpers.
+#if CROARING_IS_BIG_ENDIAN
+
+static inline uint16_t croaring_bswap16(uint16_t x) {
+    return (uint16_t)((x << 8) | (x >> 8));
+}
+
+static inline uint32_t croaring_bswap32(uint32_t x) {
+    return ((x & 0x000000FFU) << 24) | ((x & 0x0000FF00U) << 8) |
+           ((x & 0x00FF0000U) >> 8) | ((x & 0xFF000000U) >> 24);
+}
+
+static inline uint64_t croaring_bswap64(uint64_t x) {
+    return ((x & 0x00000000000000FFULL) << 56) |
+           ((x & 0x000000000000FF00ULL) << 40) |
+           ((x & 0x0000000000FF0000ULL) << 24) |
+           ((x & 0x00000000FF000000ULL) << 8) |
+           ((x & 0x000000FF00000000ULL) >> 8) |
+           ((x & 0x0000FF0000000000ULL) >> 24) |
+           ((x & 0x00FF000000000000ULL) >> 40) |
+           ((x & 0xFF00000000000000ULL) >> 56);
+}
+
+#define croaring_htole16(x) croaring_bswap16(x)
+#define croaring_htole32(x) croaring_bswap32(x)
+#define croaring_htole64(x) croaring_bswap64(x)
+
+#else  // CROARING_IS_BIG_ENDIAN
+
+#define croaring_htole16(x) (x)
+#define croaring_htole32(x) (x)
+#define croaring_htole64(x) (x)
+
+#endif  // CROARING_IS_BIG_ENDIAN
+
+#define croaring_letoh16(x) croaring_htole16(x)
+#define croaring_letoh32(x) croaring_htole32(x)
+#define croaring_letoh64(x) croaring_htole64(x)
+
 // Defines for the possible CROARING atomic implementations
 #define CROARING_ATOMIC_IMPL_NONE 1
 #define CROARING_ATOMIC_IMPL_CPP 2
@@ -547,13 +602,13 @@ static inline int roaring_hamming(uint64_t x) {
 #define CROARING_ATOMIC_IMPL CROARING_ATOMIC_IMPL_CPP
 #endif  //__has_include(<atomic>)
 #else
-   // We lack __has_include to check:
+// We lack __has_include to check:
 #define CROARING_ATOMIC_IMPL CROARING_ATOMIC_IMPL_CPP
 #endif  //__has_include
 #elif __STDC_VERSION__ >= 201112L && !defined(__STDC_NO_ATOMICS__)
 #define CROARING_ATOMIC_IMPL CROARING_ATOMIC_IMPL_C
 #elif CROARING_REGULAR_VISUAL_STUDIO
-   // https://www.technetworkhub.com/c11-atomics-in-visual-studio-2022-version-17/
+// https://www.technetworkhub.com/c11-atomics-in-visual-studio-2022-version-17/
 #define CROARING_ATOMIC_IMPL CROARING_ATOMIC_IMPL_C_WINDOWS
 #endif
 #endif  // !defined(CROARING_ATOMIC_IMPL)
@@ -8789,10 +8844,6 @@ size_t roaring_bitmap_shrink_to_fit(roaring_bitmap_t *r);
  *
  * Returns how many bytes written, should be `roaring_bitmap_size_in_bytes(r)`.
  *
- * This function is endian-sensitive. If you have a big-endian system (e.g., a
- * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
- *
  * When serializing data to a file, we recommend that you also use
  * checksums so that, at deserialization, you can be confident
  * that you are recovering the correct data.
@@ -8805,27 +8856,34 @@ size_t roaring_bitmap_serialize(const roaring_bitmap_t *r, char *buf);
  * (See `roaring_bitmap_portable_deserialize()` if you want a format that's
  * compatible with Java and Go implementations).
  *
- * This function is endian-sensitive. If you have a big-endian system (e.g., a
- * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
- *
  * The returned pointer may be NULL in case of errors.
  */
 roaring_bitmap_t *roaring_bitmap_deserialize(const void *buf);
 
 /**
+ * Load a bitmap from a serialized buffer safely (reading up to maxbytes).
+ *
  * Use with `roaring_bitmap_serialize()`.
  *
  * (See `roaring_bitmap_portable_deserialize_safe()` if you want a format that's
  * compatible with Java and Go implementations).
  *
- * This function is endian-sensitive. If you have a big-endian system (e.g., a
- * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
- *
  * The difference with `roaring_bitmap_deserialize()` is that this function
- * checks that the input buffer is a valid bitmap.  If the buffer is too small,
- * NULL is returned.
+ * is guaranteed to not read beyond the provided buffer. If the buffer is too
+ * small, NULL is returned.
+ *
+ * The function itself is safe in the sense that it will not cause buffer
+ * overflows: it will not read beyond the scope of the provided buffer
+ * (buf,maxbytes).
+ *
+ * However, for correct operations, it is assumed that the bitmap
+ * read was once serialized from a valid bitmap (i.e., it follows the format
+ * specification). If you provided an incorrect input (garbage), then the bitmap
+ * read may not be in a valid state and following operations may not lead to
+ * sensible results (using it may cause crashes, or it may just give incoherent
+ * answers). You can call roaring_bitmap_internal_validate to check the validity
+ * of the bitmap if the source is untrusted. Only after calling
+ * roaring_bitmap_internal_validate is the bitmap considered safe for use.
  *
  * The returned pointer may be NULL in case of errors.
  */
@@ -8858,10 +8916,6 @@ size_t roaring_bitmap_size_in_bytes(const roaring_bitmap_t *r);
  * This is meant to be compatible with the Java and Go versions:
  * https://github.com/RoaringBitmap/RoaringFormatSpec
  *
- * This function is endian-sensitive. If you have a big-endian system (e.g., a
- * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
- *
  * The returned pointer may be NULL in case of errors.
  */
 roaring_bitmap_t *roaring_bitmap_portable_deserialize(const char *buf);
@@ -8895,10 +8949,6 @@ roaring_bitmap_t *roaring_bitmap_portable_deserialize(const char *buf);
  * corresponds to the serialized bitmap. The CRoaring library does not provide
  * checksumming.
  *
- * This function is endian-sensitive. If you have a big-endian system (e.g., a
- * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
- *
  * The returned pointer may be NULL in case of errors.
  */
 roaring_bitmap_t *roaring_bitmap_portable_deserialize_safe(const char *buf,
@@ -8922,7 +8972,8 @@ roaring_bitmap_t *roaring_bitmap_portable_deserialize_safe(const char *buf,
  *
  * This function is endian-sensitive. If you have a big-endian system (e.g., a
  * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
+ * compatible with little-endian systems. It is not a bug, it is by design,
+ * since the format imitates C memory layout of roaring_bitmap_t.
  *
  * The returned pointer may be NULL in case of errors.
  */
@@ -8956,10 +9007,6 @@ size_t roaring_bitmap_portable_size_in_bytes(const roaring_bitmap_t *r);
  * This is meant to be compatible with the Java and Go versions:
  * https://github.com/RoaringBitmap/RoaringFormatSpec
  *
- * This function is endian-sensitive. If you have a big-endian system (e.g., a
- * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
- *
  * When serializing data to a file, we recommend that you also use
  * checksums so that, at deserialization, you can be confident
  * that you are recovering the correct data.
@@ -8996,7 +9043,8 @@ size_t roaring_bitmap_frozen_size_in_bytes(const roaring_bitmap_t *r);
  *
  * This function is endian-sensitive. If you have a big-endian system (e.g., a
  * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
+ * compatible with little-endian systems. This is not a bug, it is by design,
+ *since the format imitates C memory layout
  *
  * When serializing data to a file, we recommend that you also use
  * checksums so that, at deserialization, you can be confident
@@ -9017,7 +9065,8 @@ void roaring_bitmap_frozen_serialize(const roaring_bitmap_t *r, char *buf);
  *
  * This function is endian-sensitive. If you have a big-endian system (e.g., a
  * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
+ * compatible with little-endian systems. This is not a bug, it is by design,
+ *since the format imitates C memory layout of roaring_bitmap_t.
  */
 const roaring_bitmap_t *roaring_bitmap_frozen_view(const char *buf,
                                                    size_t length);
@@ -9038,6 +9087,16 @@ const roaring_bitmap_t *roaring_bitmap_frozen_view(const char *buf,
 bool roaring_iterate(const roaring_bitmap_t *r, roaring_iterator iterator,
                      void *ptr);
 
+/**
+ * Like `roaring_iterate`, but the 32-bit values are widened to 64 bits by
+ * adding `high_bits` (shifted into the upper 32 bits) before being passed to
+ * the iterator. This is used to build 64-bit iteration on top of 32-bit
+ * bitmaps. `ptr` (can be NULL) is forwarded as the second argument of each
+ * call.
+ *
+ * Returns true if the iterator returned true throughout (so that all values
+ * were necessarily visited).
+ */
 bool roaring_iterate64(const roaring_bitmap_t *r, roaring_iterator64 iterator,
                        uint64_t high_bits, void *ptr);
 
@@ -9611,8 +9670,14 @@ namespace roaring {
 namespace api {
 #endif
 
+/** An opaque 64-bit Roaring bitmap. Create one with `roaring64_bitmap_create()`
+ * and release it with `roaring64_bitmap_free()`. */
 typedef struct roaring64_bitmap_s roaring64_bitmap_t;
+/** Internal leaf type, exposed only for use inside `roaring64_bulk_context_t`.
+ * Callers should treat it as opaque. */
 typedef uint64_t roaring64_leaf_t;
+/** An opaque iterator over a 64-bit bitmap. See `roaring64_iterator_create()`.
+ */
 typedef struct roaring64_iterator_s roaring64_iterator_t;
 
 /**
@@ -9837,6 +9902,12 @@ bool roaring64_bitmap_contains(const roaring64_bitmap_t *r, uint64_t val);
 bool roaring64_bitmap_contains_range(const roaring64_bitmap_t *r, uint64_t min,
                                      uint64_t max);
 
+/**
+ * Returns true if all values in the range [min, max] are present.
+ */
+bool roaring64_bitmap_contains_range_closed(const roaring64_bitmap_t *r,
+                                            uint64_t min, uint64_t max);
+
 /**
  * Check if an item is present using context from a previous insert or search
  * for faster search.
@@ -10169,10 +10240,6 @@ size_t roaring64_bitmap_portable_size_in_bytes(const roaring64_bitmap_t *r);
  * This is meant to be compatible with other languages:
  * https://github.com/RoaringBitmap/RoaringFormatSpec#extension-for-64-bit-implementations
  *
- * This function is endian-sensitive. If you have a big-endian system (e.g., a
- * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
- *
  * When serializing data to a file, we recommend that you also use
  * checksums so that, at deserialization, you can be confident
  * that you are recovering the correct data.
@@ -10217,10 +10284,6 @@ size_t roaring64_bitmap_portable_deserialize_size(const char *buf,
  * We also recommend that you use checksums to check that serialized data
  * corresponds to the serialized bitmap. The CRoaring library does not provide
  * checksumming.
- *
- * This function is endian-sensitive. If you have a big-endian system (e.g., a
- * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
  */
 roaring64_bitmap_t *roaring64_bitmap_portable_deserialize_safe(const char *buf,
                                                                size_t maxbytes);
@@ -10249,7 +10312,8 @@ size_t roaring64_bitmap_frozen_size_in_bytes(const roaring64_bitmap_t *r);
  *
  * This function is endian-sensitive. If you have a big-endian system (e.g., a
  * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
+ * compatible with little-endian systems. This is not a bug, it is by design,
+ * since the format imitates C memory layout of roaring64_bitmap_t.
  */
 size_t roaring64_bitmap_frozen_serialize(const roaring64_bitmap_t *r,
                                          char *buf);
@@ -10267,7 +10331,8 @@ size_t roaring64_bitmap_frozen_serialize(const roaring64_bitmap_t *r,
  *
  * This function is endian-sensitive. If you have a big-endian system (e.g., a
  * mainframe IBM s390x), the data format is going to be big-endian and not
- * compatible with little-endian systems.
+ * compatible with little-endian systems. This is not a bug, it is by design,
+ * since the format imitates C memory layout of roaring64_bitmap_t.
  */
 roaring64_bitmap_t *roaring64_bitmap_frozen_view(const char *buf,
                                                  size_t maxbytes);