Carlo Arenas <carenas@xxxxxxxxx> writes: > On Fri, Oct 29, 2021 at 2:43 PM <rsbecker@xxxxxxxxxxxxx> 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.
