Thread (1 message) 1 message, 1 author, 2025-10-23

Re: [PATCH 3/3] rust: generate bindings via cbindgen

From: Junio C Hamano <hidden>
Date: 2025-10-23 21:42:46

Patrick Steinhardt [off-list ref] writes:
Set up this infrastructure in both our Makefile and in Meson. To
demonstrate its use, the generated "c-bindings.h" header is included in
"varint.c". If we now adapt "varint.rs" to have a different function
signature than the C code we'll now get a compiler error:

    In file included from ../varint.c:10:
    ./c-bindings.h:10:10: error: conflicting types for 'decode_varint'
       10 | uint32_t decode_varint(const uint8_t **bufp);
          |          ^
    ../varint.h:5:10: note: previous declaration is here
        5 | uint64_t decode_varint(const unsigned char **);

An initial version instead included the bindings in "varint.h". But that
would cause us to recompile all dependents of "varint.h" every time the
signatures of exported Rust functions change. So instead, we now include
it in "varint.c" and compile that file unconditionally again.

Adapt our CI to install cbindgen(1) accordingly.

Signed-off-by: Patrick Steinhardt <redacted>
---
OK.  I am getting this out of "make c-bindings.h", which looks
quite reasonable.

/**
 * Decode the variable-length integer stored in `bufp` and return the decoded value.
 *
 * Returns 0 in case the decoded integer would overflow u64::MAX.
 *
 * # Safety
 *
 * The buffer must be NUL-terminated to ensure safety.
 */
uint64_t decode_varint(const uint8_t **bufp);

/**
 * Encode `value` into `buf` as a variable-length integer unless `buf` is null.
 *
 * Returns the number of bytes written, or, if `buf` is null, the number of bytes that would be
 * written to encode the integer.
 *
 * # Safety
 *
 * `buf` must either be null or point to at least 16 bytes of memory.
 */
uint8_t encode_varint(uint64_t value, uint8_t *buf);
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help