From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 23 Oct 2025 21:42:43 GMT
Subject: Re: [PATCH 3/3] rust: generate bindings via cbindgen
Message-ID: <xmqqjz0ls3ak.fsf@gitster.g>
In-Reply-To: <20251023-b4-pks-rust-cbindgen-v1-3-c19b61b03127@pks.im>

Patrick Steinhardt <ps@pks.im> 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 <ps@pks.im>
> ---

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);