git/reftable/record.h, branch jch

reftable: fix formatting of the license header

2025-04-07T21:53:09Z

The license headers used across the reftable library doesn't follow our typical coding style for multi-line comments. Fix it. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

reftable/record: don't `BUG()` in `reftable_record_cmp()`

2025-02-18T18:55:36Z

The reftable library aborts with a bug in case `reftable_record_cmp()` is invoked with two records of differing types. This would cause the program to die without the caller being able to handle the error, which is not something we want in the context of library code. And it ties us to the Git codebase. Refactor the code such that `reftable_record_cmp()` returns an error code separate from the actual comparison result. This requires us to also adapt some callers up the callchain in a similar fashion. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

reftable/record: stop using `BUG()` in `reftable_record_init()`

2025-02-18T18:55:36Z

We're aborting the program via `BUG()` in case `reftable_record_init()` was invoked with an unknown record type. This is bad because we may now die in library code, and because it makes us depend on the Git codebase. Refactor the code such that `reftable_record_init()` can return an error code to the caller. Adapt any callers accordingly. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

reftable/basics: adjust `hash_size()` to return `uint32_t`

2025-01-21T22:20:29Z

The `hash_size()` function returns the number of bytes used by the hash function. Weirdly enough though, it returns a signed integer for its size even though the size obviously cannot ever be negative. The only case where it could be negative is if the function returned an error when asked for an unknown hash, but we assert(3p) instead. Adjust the type of `hash_size()` to be `uint32_t` and adapt all places that use signed integers for the hash size to follow suit. This also allows us to get rid of a couple asserts that we had which verified that the size was indeed positive, which further stresses the point that this refactoring makes sense. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

reftable/record: handle overflows when decoding varints

2025-01-21T22:20:28Z

The logic to decode varints isn't able to detect integer overflows: as long as the buffer still has more data available, and as long as the current byte has its 0x80 bit set, we'll continue to add up these values to the result. This will eventually cause the `uint64_t` to overflow, at which point we'll return an invalid result. Refactor the function so that it is able to detect such overflows. The implementation is basically copied from Git's own `decode_varint()`, which already knows to handle overflows. The only adjustment is that we also take into account the string view's length in order to not overrun it. The reftable documentation explicitly notes that those two encoding schemas are supposed to be the same: Varint encoding ^^^^^^^^^^^^^^^ Varint encoding is identical to the ofs-delta encoding method used within pack files. Decoder works as follows: .... val = buf[ptr] & 0x7f while (buf[ptr] & 0x80) { ptr++ val = ((val + 1) << 7) | (buf[ptr] & 0x7f) } .... While at it, refactor `put_var_int()` in the same way by copying over the implementation of `encode_varint()`. While `put_var_int()` doesn't have an issue with overflows, it generates warnings with -Wsign-compare. The implementation of `encode_varint()` doesn't, is battle-tested and at the same time way simpler than what we currently have. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

reftable/record: drop unused `print` function pointer

2025-01-21T22:20:28Z

In 42c424d69d (t/helper: inline printing of reftable records, 2024-08-22) we stopped using the `print` function of the reftable record vtable and instead moved its implementation into the single user of it. We didn't remove the function itself from the vtable though. Drop it. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

reftable/record: adapt `reftable_record_key()` to handle allocation failures

2024-10-17T20:59:56Z

The `reftable_record_key()` function cannot pass any errors to the caller as it has a `void` return type. Adapt it and its callers such that we can handle errors and start handling allocation failures. Signed-off-by: Patrick Steinhardt Signed-off-by: Taylor Blau

reftable: convert from `strbuf` to `reftable_buf`

2024-10-17T20:59:56Z

Convert the reftable library to use the `reftable_buf` interface instead of the `strbuf` interface. This is mostly a mechanical change via sed(1) with some manual fixes where functions for `strbuf` and `reftable_buf` differ. The converted code does not yet handle allocation failures. This will be handled in subsequent commits. Signed-off-by: Patrick Steinhardt Signed-off-by: Taylor Blau

reftable/record: handle allocation failures on copy

2024-10-02T14:53:52Z

Handle allocation failures when copying records. While at it, convert from `xstrdup()` to `reftable_strdup()`. Adapt callsites to check for error codes. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

t/helper: inline printing of reftable records

2024-08-22T14:59:47Z

Move printing of reftable records into the "dump-reftable" helper. This follows the same reasoning as the preceding commit. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano