From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Kyle Lippincott via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>,
Kyle Lippincott <spectral@google.com>
Subject: Re: [PATCH v2 2/3] strbuf: set errno to 0 after strbuf_getcwd
Date: Mon, 05 Aug 2024 08:51:50 -0700 [thread overview]
Message-ID: <xmqqv80f3r3d.fsf@gitster.g> (raw)
In-Reply-To: <CAPig+cTmzk7AN2x8-WCK_T5-_G7Wd-akB2++_4HFEbT67Rnc8A@mail.gmail.com> (Eric Sunshine's message of "Fri, 2 Aug 2024 17:54:08 -0400")
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Fri, Aug 2, 2024 at 5:32 PM Junio C Hamano <gitster@pobox.com> wrote:
>> > [...]
>> > Set `errno = 0;` prior to exiting from `strbuf_getcwd` successfully.
>> > This matches the behavior in functions like `run_transaction_hook`
>> > (refs.c:2176) and `read_ref_internal` (refs/files-backend.c:564).
>>
>> I am still uneasy to see this unconditional clearing, which looks
>> more like spreading the bad practice from two places you identified
>> than following good behaviour modelled after these two places.
>>
>> But I'll let it pass.
>>
>> As long as our programmers understand that across strbuf_getcwd(),
>> errno will *not* be preserved, even if the function returns success,
>> it would be OK. As the usual convention around errno is that a
>> successful call would leave errno intact, not clear it to 0, it
>> would make it a bit harder to learn our API for newcomers, though.
>
> For what it's worth, I share your misgivings about this change and
> consider the suggestion[*] to make it save/restore `errno` upon
> success more sensible. It would also be a welcome change to see the
> function documentation in strbuf.h updated to mention that it follows
> the usual convention of leaving `errno` untouched upon success and
> clobbered upon error.
>
> [*]: https://lore.kernel.org/git/xmqqv80jeza5.fsf@gitster.g/
Yup, of course save/restore would be safer, and probably easier to
reason about for many people.
Thanks.
next prev parent reply other threads:[~2024-08-05 15:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-02 4:10 [PATCH 0/3] Small fixes for issues detected during internal CI runs Kyle Lippincott via GitGitGadget
2024-08-02 4:10 ` [PATCH 1/3] set errno=0 before strtoX calls Kyle Lippincott via GitGitGadget
2024-08-02 5:12 ` Patrick Steinhardt
2024-08-02 6:15 ` Kyle Lippincott
2024-08-02 15:01 ` Junio C Hamano
2024-08-02 4:10 ` [PATCH 2/3] strbuf: set errno to 0 after strbuf_getcwd Kyle Lippincott via GitGitGadget
2024-08-02 15:10 ` Junio C Hamano
2024-08-02 17:56 ` Kyle Lippincott
2024-08-02 4:10 ` [PATCH 3/3] t6421: fix test to work when repo dir contains d0 Kyle Lippincott via GitGitGadget
2024-08-02 15:13 ` Junio C Hamano
2024-08-02 20:58 ` [PATCH v2 0/3] Small fixes for issues detected during internal CI runs Kyle Lippincott via GitGitGadget
2024-08-02 20:58 ` [PATCH v2 1/3] set errno=0 before strtoX calls Kyle Lippincott via GitGitGadget
2024-08-02 21:18 ` Junio C Hamano
2024-08-02 20:58 ` [PATCH v2 2/3] strbuf: set errno to 0 after strbuf_getcwd Kyle Lippincott via GitGitGadget
2024-08-02 21:32 ` Junio C Hamano
2024-08-02 21:54 ` Eric Sunshine
2024-08-05 15:51 ` Junio C Hamano [this message]
2024-08-06 6:26 ` Patrick Steinhardt
2024-08-06 7:04 ` Kyle Lippincott
2024-08-02 23:51 ` Kyle Lippincott
2024-08-05 17:12 ` Kyle Lippincott
2024-08-02 20:58 ` [PATCH v2 3/3] t6421: fix test to work when repo dir contains d0 Kyle Lippincott via GitGitGadget
2024-08-02 21:41 ` Junio C Hamano
2024-08-03 0:03 ` Kyle Lippincott
2024-08-03 0:27 ` Junio C Hamano
2024-08-05 17:10 ` [PATCH v3 0/2] Small fixes for issues detected during internal CI runs Kyle Lippincott via GitGitGadget
2024-08-05 17:10 ` [PATCH v3 1/2] set errno=0 before strtoX calls Kyle Lippincott via GitGitGadget
2024-08-05 17:10 ` [PATCH v3 2/2] t6421: fix test to work when repo dir contains d0 Kyle Lippincott via GitGitGadget
2024-08-05 18:37 ` [PATCH v3 0/2] Small fixes for issues detected during internal CI runs Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqv80f3r3d.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=ps@pks.im \
--cc=spectral@google.com \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.