Re: [PATCH 4/4] t-reftable-merged: check realloc errors

From: René Scharfe <l.s.r@web.de>
Date: Dec 27, 2024, 20:16 UTC
Message-ID: <6112daa0-190e-4d15-9b00-98fbc2a69fa3@web.de>
In-Reply-To: <Z26CmZEMQeqGFuEs@pks.im>

Am 27.12.24 um 11:34 schrieb Patrick Steinhardt:

Show 16 quoted lines

> On Thu, Dec 26, 2024 at 09:46:51PM -0800, Junio C Hamano wrote:
>> René Scharfe <l.s.r@web.de> writes:
>>
>>> Report reallocation errors in unit tests, like everywhere else.
>>
>> OK.  That's good for consistency if anything else.
>>
>> We have a test framework for doing unit test at such low level, yet
>> we cannot really write tests that validates that the right thing
>> happens when a particular realloc() call returns NULL, which feels
>> somewhat disappointing, but that is not a fault of this series.
>
> In the context of the reftable library we can because we've got
> pluggable allocators. We could in theory swap them out against variants
> that fail, but it's not easy to make them fail in one specific code
> path. For the case at hand though it would work alright.

It should be easy and safe to provide allocator stubs that just fail and swap them in and out with reftable_set_alloc() before and after an operation that performs a single allocation. Will add basic tests in the next round.

Injecting an allocation error in the middle of parse_names() would require a version that starts failing after a certain number of allocations (or allocated bytes). Possible, but not in scope for this series.

René