Re: [PATCH] wrapper: remove xunsetenv()
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 29, 2021, 21:56 UTC
- Message-ID
- <xmqqk0hvijgg.fsf@gitster.g>
- In-Reply-To
- <CAPUEsphuqsxUmaH6wRWi_+HT+ukyRxfuPe6hKoJt9kc-GRxBjA@mail.gmail.com>
Carlo Arenas <carenas@gmail.com> writes:
Show 28 quoted lines
> On Fri, Oct 29, 2021 at 2:43 PM <rsbecker@nexbridge.com> wrote: >> >> On October 29, 2021 5:37 PM, Jeff King wrote: >> > On Fri, Oct 29, 2021 at 02:27:05PM -0700, Carlo Marcelo Arenas Belón wrote: >> > >> > > Remove the unused wrapper function. >> > >> > I don't mind removing this if nobody is using it, but doesn't your first paragraph >> > argue that our definition of gitunsetenv() is just wrong? >> > I.e., it should return an int, even if it is always "0"? > > I couldn't figure the intent Jason had when this code was added in > 2006, but considering how Junio suggested using void for the wrapper, > my guess is that we really wanted to make sure nobody will consider > errors for that function as actionable. > >> > Or is it a portability question? I.e., are there platforms where >> > unsetenv() also returns void, in which case we must make sure nobody ever >> > looks at its return value (and xunsetenv() is therefore a wrong direction)? >> >> At least on NonStop x86, it is >> >> int unsetenv(const char *name); > > I don't think there is any platform that had anything but int, and so > I agree with you that it would be much better if the compatibility > layer returns 0, but as you pointed out, this was the safest approach > considering we are 1 day after rc0 ;)
I do not plan to have *ANYTHING* I first see today in -rc0. Not even near 'next'. No way.
Thanks.