From: Derrick Stolee <derrickstolee@github.com>
To: Taylor Blau <me@ttaylorr.com>, Glen Choo <chooglen@google.com>
Cc: Glen Choo via GitGitGadget <gitgitgadget@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] config.c: NULL check when reading protected config
Date: Tue, 26 Jul 2022 13:51:17 -0400 [thread overview]
Message-ID: <47c0803c-bd98-0460-1e9f-c37dc3deeb8d@github.com> (raw)
In-Reply-To: <YuAn171BhecC1w+O@nand.local>
On 7/26/2022 1:43 PM, Taylor Blau wrote:
> On Tue, Jul 26, 2022 at 10:40:18AM -0700, Glen Choo wrote:
>>> I wonder: should it become a BUG() to call git_configset_add_file() with
>>> a NULL filename? That would have elevated the test failure outside of
>>> just the ASAn builds, I'd think.
>>>
>>> There's certainty a risk of being too defensive, but elevating this
>>> error beyond just the ASan builds indicates that this would be an
>>> appropriate layer of defense IMHO.
>>
>> Hm, if we're going in this direction, what if we made it a BUG() to call
>> fopen_or_warn() with a NULL filename? Then we wouldn't have to
>> reimplement this BUG() check in all of its callers.
>
> That may be too low-level of a place to put this check, but I don't have
> a strong opinion about it either way (including whether we should have
> such a BUG() *anywhere* in this series, including
> git_configset_add_file()).
Since git_configset_add_file() returns an 'int', could we return -1
if the supplied 'filename' was null? (The correct place to check would
be down in git_config_from_file_with_options().)
It would save all these checks here.
(Also: do we care that we are ignoring the return values in
read_protected_config()?
Thanks,
-Stolee
next prev parent reply other threads:[~2022-07-26 17:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-26 17:09 [PATCH] config.c: NULL check when reading protected config Glen Choo via GitGitGadget
2022-07-26 17:27 ` Taylor Blau
2022-07-26 17:40 ` Glen Choo
2022-07-26 17:43 ` Taylor Blau
2022-07-26 17:51 ` Derrick Stolee [this message]
2022-07-26 19:42 ` Glen Choo
2022-07-26 19:03 ` Ævar Arnfjörð Bjarmason
2022-07-26 19:59 ` Glen Choo
2022-07-27 9:08 ` Ævar Arnfjörð Bjarmason
2022-07-26 22:21 ` [PATCH v2] " Glen Choo via GitGitGadget
2022-07-27 9:12 ` nonnull v.s. BUG() if !x (was: [PATCH v2] config.c: NULL check when reading protected config) Ævar Arnfjörð Bjarmason
2022-07-27 17:07 ` Glen Choo
2022-07-27 15:00 ` [PATCH v2] config.c: NULL check when reading protected config Junio C Hamano
2022-07-27 16:52 ` Glen Choo
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=47c0803c-bd98-0460-1e9f-c37dc3deeb8d@github.com \
--to=derrickstolee@github.com \
--cc=chooglen@google.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=me@ttaylorr.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.