Re: [PATCH 0/6] getenv() timing fixes

From: Stefan Beller <sbeller@google.com>
Date: Jan 15, 2019, 19:38 UTC
Message-ID: <CAGZ79kbbhdFCPbEEZzwmti0zTDCG429Moa-T77DNmCx07svM2A@mail.gmail.com>
In-Reply-To: <xmqqy37lra1j.fsf@gitster-ct.c.googlers.com>

On Tue, Jan 15, 2019 at 11:32 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 21 quoted lines

>
> Jeff King <peff@peff.net> writes:
>
> > On Sat, Jan 12, 2019 at 10:51:42AM -0800, Stefan Beller wrote:
> >
> >> > I wonder, and not as "you should do this" feedback on this series, just
> >>
> >> There is a getenv_safe() in environment.c, but I guess a xgetenv() that
> >> takes the same parameters as getenv() is better for ease of use.
> >
> > Yes, but it punts on the memory ownership by stuffing everything into an
> > argv_array. That saves a few lines if you're going to ask for five
> > variables, but for a single variable it's no better than:
> >
> >   char *foo = getenv_safe("FOO");
>
> You meant xstrdup_or_null(getenv("FOO")) here?  And did Stefan mean
>
>         #define xgetenv(e) xstrdup_or_null(getenv(e))
>
> ?

Assume I did. (I thought of it as a function effectively adding the xstrdup_or_null)

If we go further into assuming the usage patterns of these xgetenv calls, we might throw in an UNLEAK as well, but that might be over board.