Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update to 4.1.2 #154

Closed
wants to merge 2 commits into from
Closed

Update to 4.1.2 #154

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c44187c
chore: update bindings to 4.1.4
Dr-Emann Sep 5, 2024
7d70df2
feat: add From<Bitmap> for Bitmap64
Dr-Emann Sep 5, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
253 changes: 149 additions & 104 deletions Cargo.lock
View file
Open in desktop

Large diffs are not rendered by default.

2 changes: 1 addition & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -127,7 +127,7 @@ Current documentation is available at https://docs.rs/croaring/latest/croaring/

## CRoaring Version

This crate uses [CRoaring version `4.1.1`](https://github.com/RoaringBitmap/CRoaring/releases/tag/v4.1.1).
This crate uses [CRoaring version `4.1.4`](https://github.com/RoaringBitmap/CRoaring/releases/tag/v4.1.4).
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.
24 changes: 15 additions & 9 deletions croaring-sys/CRoaring/bindgen_bundled_version.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
/* automatically generated by rust-bindgen 0.69.4 */
/* automatically generated by rust-bindgen 0.70.1 */

pub const ROARING_VERSION: &[u8; 6] = b"4.1.1\0";
pub const ROARING_VERSION: &[u8; 6] = b"4.1.4\0";
pub const ROARING_VERSION_MAJOR: _bindgen_ty_1 = 4;
pub const ROARING_VERSION_MINOR: _bindgen_ty_1 = 1;
pub const ROARING_VERSION_REVISION: _bindgen_ty_1 = 1;
pub const ROARING_VERSION_REVISION: _bindgen_ty_1 = 4;
pub type _bindgen_ty_1 = ::core::ffi::c_uint;
extern "C" {
#[doc = " result might be undefined when input_num is zero"]
Expand Down Expand Up @@ -516,7 +516,7 @@ extern "C" {
pub fn roaring_bitmap_shrink_to_fit(r: *mut roaring_bitmap_t) -> usize;
}
extern "C" {
#[doc = " Write the bitmap to an output pointer, this output buffer should refer to\n at least `roaring_bitmap_size_in_bytes(r)` allocated bytes.\n\n See `roaring_bitmap_portable_serialize()` if you want a format that's\n compatible with Java and Go implementations. This format can sometimes be\n more space efficient than the portable form, e.g. when the data is sparse.\n\n Returns how many bytes written, should be `roaring_bitmap_size_in_bytes(r)`.\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems."]
#[doc = " Write the bitmap to an output pointer, this output buffer should refer to\n at least `roaring_bitmap_size_in_bytes(r)` allocated bytes.\n\n See `roaring_bitmap_portable_serialize()` if you want a format that's\n compatible with Java and Go implementations. This format can sometimes be\n more space efficient than the portable form, e.g. when the data is sparse.\n\n Returns how many bytes written, should be `roaring_bitmap_size_in_bytes(r)`.\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems.\n\n When serializing data to a file, we recommend that you also use\n checksums so that, at deserialization, you can be confident\n that you are recovering the correct data."]
pub fn roaring_bitmap_serialize(
r: *const roaring_bitmap_t,
buf: *mut ::core::ffi::c_char,
Expand Down Expand Up @@ -544,7 +544,7 @@ extern "C" {
) -> *mut roaring_bitmap_t;
}
extern "C" {
#[doc = " Read bitmap from a serialized buffer safely (reading up to maxbytes).\n In case of failure, NULL is returned.\n\n This is meant to be compatible with the Java and Go versions:\n https://github.com/RoaringBitmap/RoaringFormatSpec\n\n The function itself is safe in the sense that it will not cause buffer\n overflows. However, for correct operations, it is assumed that the bitmap\n read was once serialized from a valid bitmap (i.e., it follows the format\n specification). If you provided an incorrect input (garbage), then the bitmap\n read may not be in a valid state and following operations may not lead to\n sensible results. In particular, the serialized array containers need to be\n in sorted order, and the run containers should be in sorted non-overlapping\n order. This is is guaranteed to happen when serializing an existing bitmap,\n but not for random inputs.\n\n You may use roaring_bitmap_internal_validate to check the validity of the\n bitmap prior to using it. You may also use other strategies to check for\n corrupted inputs (e.g., checksums).\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems."]
#[doc = " Read bitmap from a serialized buffer safely (reading up to maxbytes).\n In case of failure, NULL is returned.\n\n This is meant to be compatible with the Java and Go versions:\n https://github.com/RoaringBitmap/RoaringFormatSpec\n\n The function itself is safe in the sense that it will not cause buffer\n overflows: it will not read beyond the scope of the provided buffer\n (buf,maxbytes).\n\n However, for correct operations, it is assumed that the bitmap\n read was once serialized from a valid bitmap (i.e., it follows the format\n specification). If you provided an incorrect input (garbage), then the bitmap\n read may not be in a valid state and following operations may not lead to\n sensible results. In particular, the serialized array containers need to be\n in sorted order, and the run containers should be in sorted non-overlapping\n order. This is is guaranteed to happen when serializing an existing bitmap,\n but not for random inputs.\n\n You may use roaring_bitmap_internal_validate to check the validity of the\n bitmap prior to using it.\n\n We recommend that you use checksums to check that serialized data corresponds\n to a serialized bitmap.\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems."]
pub fn roaring_bitmap_portable_deserialize_safe(
buf: *const ::core::ffi::c_char,
maxbytes: usize,
Expand All @@ -568,7 +568,7 @@ extern "C" {
pub fn roaring_bitmap_portable_size_in_bytes(r: *const roaring_bitmap_t) -> usize;
}
extern "C" {
#[doc = " Write a bitmap to a char buffer. The output buffer should refer to at least\n `roaring_bitmap_portable_size_in_bytes(r)` bytes of allocated memory.\n\n Returns how many bytes were written which should match\n `roaring_bitmap_portable_size_in_bytes(r)`.\n\n This is meant to be compatible with the Java and Go versions:\n https://github.com/RoaringBitmap/RoaringFormatSpec\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems."]
#[doc = " Write a bitmap to a char buffer. The output buffer should refer to at least\n `roaring_bitmap_portable_size_in_bytes(r)` bytes of allocated memory.\n\n Returns how many bytes were written which should match\n `roaring_bitmap_portable_size_in_bytes(r)`.\n\n This is meant to be compatible with the Java and Go versions:\n https://github.com/RoaringBitmap/RoaringFormatSpec\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems.\n\n When serializing data to a file, we recommend that you also use\n checksums so that, at deserialization, you can be confident\n that you are recovering the correct data."]
pub fn roaring_bitmap_portable_serialize(
r: *const roaring_bitmap_t,
buf: *mut ::core::ffi::c_char,
Expand All @@ -579,7 +579,7 @@ extern "C" {
pub fn roaring_bitmap_frozen_size_in_bytes(r: *const roaring_bitmap_t) -> usize;
}
extern "C" {
#[doc = " Serializes bitmap using frozen format.\n Buffer size must be at least roaring_bitmap_frozen_size_in_bytes().\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems."]
#[doc = " Serializes bitmap using frozen format.\n Buffer size must be at least roaring_bitmap_frozen_size_in_bytes().\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems.\n\n When serializing data to a file, we recommend that you also use\n checksums so that, at deserialization, you can be confident\n that you are recovering the correct data."]
pub fn roaring_bitmap_frozen_serialize(
r: *const roaring_bitmap_t,
buf: *mut ::core::ffi::c_char,
Expand Down Expand Up @@ -861,6 +861,12 @@ extern "C" {
#[doc = " Creates a new bitmap of a pointer to N 64-bit integers."]
pub fn roaring64_bitmap_of_ptr(n_args: usize, vals: *const u64) -> *mut roaring64_bitmap_t;
}
extern "C" {
#[doc = " Create a new bitmap by moving containers from a 32 bit roaring bitmap.\n\n After calling this function, the original bitmap will be empty, and the\n returned bitmap will contain all the values from the original bitmap."]
pub fn roaring64_bitmap_move_from_roaring32(
r: *mut roaring_bitmap_t,
) -> *mut roaring64_bitmap_t;
}
extern "C" {
#[doc = " Create a new bitmap containing all the values in [min, max) that are at a\n distance k*step from min."]
pub fn roaring64_bitmap_from_range(min: u64, max: u64, step: u64) -> *mut roaring64_bitmap_t;
Expand Down Expand Up @@ -1166,7 +1172,7 @@ extern "C" {
pub fn roaring64_bitmap_portable_size_in_bytes(r: *const roaring64_bitmap_t) -> usize;
}
extern "C" {
#[doc = " Write a bitmap to a buffer. The output buffer should refer to at least\n `roaring64_bitmap_portable_size_in_bytes(r)` bytes of allocated memory.\n\n Returns how many bytes were written, which should match\n `roaring64_bitmap_portable_size_in_bytes(r)`.\n\n This is meant to be compatible with other languages:\n https://github.com/RoaringBitmap/RoaringFormatSpec#extension-for-64-bit-implementations\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems."]
#[doc = " Write a bitmap to a buffer. The output buffer should refer to at least\n `roaring64_bitmap_portable_size_in_bytes(r)` bytes of allocated memory.\n\n Returns how many bytes were written, which should match\n `roaring64_bitmap_portable_size_in_bytes(r)`.\n\n This is meant to be compatible with other languages:\n https://github.com/RoaringBitmap/RoaringFormatSpec#extension-for-64-bit-implementations\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems.\n\n When serializing data to a file, we recommend that you also use\n checksums so that, at deserialization, you can be confident\n that you are recovering the correct data."]
pub fn roaring64_bitmap_portable_serialize(
r: *const roaring64_bitmap_t,
buf: *mut ::core::ffi::c_char,
Expand All @@ -1180,7 +1186,7 @@ extern "C" {
) -> usize;
}
extern "C" {
#[doc = " Read a bitmap from a serialized buffer safely (reading up to maxbytes).\n In case of failure, NULL is returned.\n\n This is meant to be compatible with other languages\n https://github.com/RoaringBitmap/RoaringFormatSpec#extension-for-64-bit-implementations\n\n The function itself is safe in the sense that it will not cause buffer\n overflows. However, for correct operations, it is assumed that the bitmap\n read was once serialized from a valid bitmap (i.e., it follows the format\n specification). If you provided an incorrect input (garbage), then the bitmap\n read may not be in a valid state and following operations may not lead to\n sensible results. In particular, the serialized array containers need to be\n in sorted order, and the run containers should be in sorted non-overlapping\n order. This is is guaranteed to happen when serializing an existing bitmap,\n but not for random inputs.\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems."]
#[doc = " Read a bitmap from a serialized buffer (reading up to maxbytes).\n In case of failure, NULL is returned.\n\n This is meant to be compatible with other languages\n https://github.com/RoaringBitmap/RoaringFormatSpec#extension-for-64-bit-implementations\n\n The function itself is safe in the sense that it will not cause buffer\n overflows: it will not read beyond the scope of the provided buffer\n (buf,maxbytes).\n\n However, for correct operations, it is assumed that the bitmap\n read was once serialized from a valid bitmap (i.e., it follows the format\n specification). If you provided an incorrect input (garbage), then the bitmap\n read may not be in a valid state and following operations may not lead to\n sensible results. In particular, the serialized array containers need to be\n in sorted order, and the run containers should be in sorted non-overlapping\n order. This is is guaranteed to happen when serializing an existing bitmap,\n but not for random inputs.\n\n You may use roaring64_bitmap_internal_validate to check the validity of the\n bitmap prior to using it.\n\n We recommend that you use checksums to check that serialized data corresponds\n to a serialized bitmap.\n\n This function is endian-sensitive. If you have a big-endian system (e.g., a\n mainframe IBM s390x), the data format is going to be big-endian and not\n compatible with little-endian systems."]
pub fn roaring64_bitmap_portable_deserialize_safe(
buf: *const ::core::ffi::c_char,
maxbytes: usize,
Expand Down
Loading
Loading