From: Taylor Blau <me@ttaylorr.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Derrick Stolee <dstolee@microsoft.com>,
Jeff Hostetler <git@jeffhostetler.com>,
Patrick Steinhardt <ps@pks.im>, Jeff King <peff@peff.net>
Subject: Re: [PATCH v3 1/5] wrapper.c: add x{un,}setenv(), and use xsetenv() in environment.c
Date: Mon, 20 Sep 2021 17:53:49 -0400 [thread overview]
Message-ID: <YUkC7RIDR7pQWsPh@nand.local> (raw)
In-Reply-To: <patch-v3-1.5-4b320edc933-20210919T084703Z-avarab@gmail.com>
On Sun, Sep 19, 2021 at 10:47:15AM +0200, Ævar Arnfjörð Bjarmason wrote:
> Add fatal wrappers for setenv() and unsetenv(). In d7ac12b25d3 (Add
> set_git_dir() function, 2007-08-01) we started checking its return
> value, and since 48988c4d0c3 (set_git_dir: die when setenv() fails,
> 2018-03-30) we've had set_git_dir_1() die if we couldn't set it.
>
> Let's provide a wrapper for both, this will be useful in many other
> places, a subsequent patch will make another use of xsetenv().
Makes sense.
> We could make these return "void" (as far as I can tell there's no
> other x*() wrappers that needed to make that decision before),
> i.e. our "return 0" is only to indicate that we didn't error, which we
> would have died on. Let's return "int" instead to be consistent with
> the C library function signatures, including for any future code that
> expects a pointer to a setenv()-like function.
This may be a little over-clever ;). It is cute, but returning an int
makes xsetenv a drop-in replacement for setenv. Which is nice, but it
makes it all too-easy to take code like:
if (setenv(...) < 0)
die(_("..."));
and replace it with
if (xsetenv(...) < 0)
which makes the whole conditional redundant, since the wrappers are
guaranteed not to return an error.
In other words, I like the idea that s/setenv/x&/ causes a compile-time
error, and returning an int from these wrappers prevents that from
happening.
This may be a little too-theoretical, and you're certainly free to
disagree, just my $0.02.
> I think it would be OK skip the NULL check of the "name" here for the
> calls to die_errno(). Almost all of our setenv() callers are taking a
> constant string hardcoded in the source as the first argument, and for
> the rest we can probably assume they've done the NULL check
> themselves. Even if they didn't, modern C libraries are forgiving
> about it (e.g. glibc formatting it as "(null)"), on those that aren't,
> well, we were about to die anyway. But let's include the check anyway
> for good measure.
This I think is a good call. I agree in practice that most times we'd be
just fine to pass null to printf() (as we have seen from 88617d11f9
(multi-pack-index: fix potential segfault without sub-command,
2021-07-19) ;)). But there's no reason to rely on risky assumptions when
it's easy to avoid doing so.
> diff --git a/wrapper.c b/wrapper.c
> index 7c6586af321..95f989260cd 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -145,6 +145,21 @@ void *xcalloc(size_t nmemb, size_t size)
> return ret;
> }
>
> +int xsetenv(const char *name, const char *value, int overwrite)
> +{
> + if (setenv(name, value, overwrite))
> + die_errno("setenv(%s, '%s', %d) failed", name ? name : "(null)",
> + value, overwrite);
> + return 0;
> +}
> +
> +int xunsetenv(const char *name)
> +{
> + if (!unsetenv(name))
> + die_errno("unsetenv(%s) failed", name ? name : "(null)");
> + return 0;
> +}
> +
For what it's worth, I find these new messages a little wordy. Maybe
we should just sticky "could not (un)set %s"?
Thanks,
Taylor
next prev parent reply other threads:[~2021-09-21 2:20 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-16 18:30 [PATCH v2 0/5] repo-settings.c: refactor for clarity, get rid of hacks etc Ævar Arnfjörð Bjarmason
2021-09-16 18:30 ` [PATCH v2 1/5] wrapper.c: add x{un,}setenv(), and use xsetenv() in environment.c Ævar Arnfjörð Bjarmason
2021-09-17 16:57 ` Junio C Hamano
2021-09-17 19:18 ` Ævar Arnfjörð Bjarmason
2021-09-16 18:30 ` [PATCH v2 2/5] environment.c: remove test-specific "ignore_untracked..." variable Ævar Arnfjörð Bjarmason
2021-09-17 17:19 ` Junio C Hamano
2021-09-16 18:30 ` [PATCH v2 3/5] read-cache & fetch-negotiator: check "enum" values in switch() Ævar Arnfjörð Bjarmason
2021-09-17 19:30 ` Junio C Hamano
2021-09-16 18:30 ` [PATCH v2 4/5] repo-settings.c: simplify the setup Ævar Arnfjörð Bjarmason
2021-09-16 18:30 ` [PATCH v2 5/5] repository.h: don't use a mix of int and bitfields Ævar Arnfjörð Bjarmason
2021-09-19 8:47 ` [PATCH v3 0/5] repo-settings.c: refactor for clarity, get rid of hacks etc Ævar Arnfjörð Bjarmason
2021-09-19 8:47 ` [PATCH v3 1/5] wrapper.c: add x{un,}setenv(), and use xsetenv() in environment.c Ævar Arnfjörð Bjarmason
2021-09-20 21:53 ` Taylor Blau [this message]
2021-09-20 23:17 ` Ævar Arnfjörð Bjarmason
2021-09-19 8:47 ` [PATCH v3 2/5] environment.c: remove test-specific "ignore_untracked..." variable Ævar Arnfjörð Bjarmason
2021-09-20 22:10 ` Taylor Blau
2021-09-20 23:27 ` Ævar Arnfjörð Bjarmason
2021-09-19 8:47 ` [PATCH v3 3/5] read-cache & fetch-negotiator: check "enum" values in switch() Ævar Arnfjörð Bjarmason
2021-09-20 22:14 ` Taylor Blau
2021-09-20 23:33 ` Ævar Arnfjörð Bjarmason
2021-09-19 8:47 ` [PATCH v3 4/5] repo-settings.c: simplify the setup Ævar Arnfjörð Bjarmason
2021-09-20 12:42 ` Derrick Stolee
2021-09-20 22:18 ` Taylor Blau
2021-09-19 8:47 ` [PATCH v3 5/5] repository.h: don't use a mix of int and bitfields Ævar Arnfjörð Bjarmason
2021-09-20 22:25 ` Taylor Blau
2021-09-21 13:12 ` [PATCH v4 0/5] repo-settings.c: refactor for clarity, get rid of hacks etc Ævar Arnfjörð Bjarmason
2021-09-21 13:12 ` [PATCH v4 1/5] wrapper.c: add x{un,}setenv(), and use xsetenv() in environment.c Ævar Arnfjörð Bjarmason
2021-09-21 13:13 ` [PATCH v4 2/5] environment.c: remove test-specific "ignore_untracked..." variable Ævar Arnfjörð Bjarmason
2021-09-21 13:13 ` [PATCH v4 3/5] read-cache & fetch-negotiator: check "enum" values in switch() Ævar Arnfjörð Bjarmason
2021-09-21 13:13 ` [PATCH v4 4/5] repo-settings.c: simplify the setup Ævar Arnfjörð Bjarmason
2021-09-21 13:13 ` [PATCH v4 5/5] repository.h: don't use a mix of int and bitfields Ævar Arnfjörð Bjarmason
2021-09-21 15:58 ` [PATCH v4 0/5] repo-settings.c: refactor for clarity, get rid of hacks etc Derrick Stolee
2021-09-21 20:46 ` Taylor Blau
2021-09-22 20:23 ` 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=YUkC7RIDR7pQWsPh@nand.local \
--to=me@ttaylorr.com \
--cc=avarab@gmail.com \
--cc=dstolee@microsoft.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).