On Tue, Dec 29, 2020 at 4:21 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Back in 2001 we decided to prefer putenv() over setenv() because the > latter wasn't in POSIX (SUSv2) at the time. That decision has been > overtaken by events: more recent editions of POSIX not only provide > setenv() but recommend it over putenv(). So I think it's time to > change our policy and prefer setenv(). We've had previous discussions > about that but nobody did the legwork yet. > > The attached patch provides the infrastructure to allow using setenv(). > I added a src/port/ implementation of setenv() for any machines that > haven't caught up with POSIX lately. (I've tested that code on my old > dinosaur gaur, and I would not be surprised if that is the only machine > anywhere that ever runs it. But I could be wrong.) I also extended > win32env.c to support setenv().
+1, nice modernisation. > 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? 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. [1] https://github.com/NetBSD/src/commit/13dee93fb3a93189a74a3705a5f7cd1c6b290125 [2] https://github.com/openbsd/src/commit/471b62eeaa7f3a18c0aa98b5d605e5cec1625b62 [3] https://github.com/freebsd/freebsd/commit/196b6346ba4e13a3f7679e2de3317b6aa65983df
