Thomas Munro <thomas.munro@gmail.com> writes:
> On Tue, Dec 29, 2020 at 4:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I also changed our unsetenv() emulations to make them return an int
>> error indicator, as per POSIX. I have no desire to change the call
>> sites to check for errors, but it seemed like our compatibility stubs
>> should be compatible with the spec. (Note: I think that unsetenv()
>> did return void in old BSD versions, before POSIX standardized it.
>> So that might be a real reason not to change the callers.)
> +1 for conformance. I suppose it's out of spec that unsetenv() can
> return -1 with errno = ENOMEM (from malloc()), but that hardly
> matters. Hmm... could a static buffer be used for that clobbering
> trick?
Hm, hadn't thought about that particularly. I did think about
hacking setenv.c to try to reduce memory leakage from repeated
sets of the same variable (basically, try to overwrite the existing
environ member whenever the new value is no longer than the old).
But on the whole I think it'd all be wasted effort. Neither setenv.c
nor unsetenv.c will ever be used on any machine that anyone would care
about performance of. If I were willing to retire gaur I'd vote for
just nuking both of them.
> For the note in parens: it looks like the 3 main BSDs all switched
> from the historical void function to the POSIX one 12-18 years
> ago[1][2][3], so I wouldn't worry about that. Glibc made a similar
> change 19 years ago.
Ah, thanks for the research. I'd found the glibc change from references
in current Linux man pages, but I didn't run down the BSD history.
(My other pet dinosaur prairiedog still has void unsetenv(), btw,
presumably because macOS is based on turn-of-the-century NetBSD.
Modern macOS does follow POSIX here; not sure when they changed.)
regards, tom lane
