On Thursday, October 10th, 2024 at 15:03, Junio C Hamano <gitster@xxxxxxxxx> wrote: > That does not say what should be left in the strbuf when the request > failed. If it is undefined, then using its .len (or .buf) is not > quite right, without relying on too much implementation details of > the called function. > > Usually, this project uses 0 to signal a success, while errors are > signalled by returning a negative value (and if there can be > multiple ways to fail, such a design leaves different negative > values as a possibility). > > If the result the caller finds useful is always positive value (or > non-negative value), however, it is perfectly fine and often more > convenient if you used the "positive (or non-negative) value gives > the intended result and signals a success, negative (or > non-positive) value signals an error" convention. The caller can > > if (0 < do_the_thing()) > ; /* success / > > just fine, instead of the boolean "0 is success, negative values are > various errors", > > if (!do_the_thing()) > ; / success */ > > when it does not care how/why the thing failed. That makes sense. I can update the function to return -1 on error and the strbuf.len on success.
Attachment:
signature.asc
Description: OpenPGP digital signature
