summaryrefslogtreecommitdiff
path: root/t/unit-tests/t-basic.c
diff options
context:
space:
mode:
authorPatrick Steinhardt <ps@pks.im>2024-03-25 11:02:38 +0100
committerJunio C Hamano <gitster@pobox.com>2024-03-25 09:51:11 -0700
commit630942a873ae0f1d067efaaf7b4d1b05cfb3a141 (patch)
tree511a0c02a9fd49379578fe618b3e8d07e2bfbec6 /t/unit-tests/t-basic.c
parent667b545c625a860b42f335db3c5a04020e6131f6 (diff)
reftable/stack: fix error handling in `reftable_stack_init_addition()`
In `reftable_stack_init_addition()` we call `stack_uptodate()` after having created the lockfile to check whether the stack was modified concurrently, which is indicated by a positive return code from the latter function. If so, we return a `REFTABLE_LOCK_ERROR` to the caller and abort the addition. The error handling has an off-by-one though because we check whether the error code is `> 1` instead of `> 0`. Thus, instead of returning the locking error, we would return a positive value. One of the callers of `reftable_stack_init_addition()` works around this bug by repeating the error code check without the off-by-one. But other callers are subtly broken by this bug. Fix this by checking for `err > 0` instead. This has the consequence that `reftable_stack_init_addition()` won't ever return a positive error code anymore, but will instead return `REFTABLE_LOCK_ERROR` now. Thus, we can drop the check for a positive error code in `stack_try_add()` now. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/unit-tests/t-basic.c')
0 files changed, 0 insertions, 0 deletions