Unportable(?) use of setenv() in secure_open_gssapi()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Unportable(?) use of setenv() in secure_open_gssapi()
Date: 2019-12-16 23:22:58
Message-ID: 30119.1576538578@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I noticed while investigating [1] that we have one single solitary
use of setenv(3) in our code base, in secure_open_gssapi().

It's been project policy since 2001 to avoid setenv(), and I notice
that src/port/win32env.c lacks support for setenv(), making it
pretty doubtful that the call has the semantics one would wish
on Windows.

Now, versions of the POSIX spec released in this century do have setenv(),
and even seem to regard it as "more standard" than putenv(). So maybe
there's a case for moving our goalposts and deciding to allow use of
setenv(). But then it seems like we'd better twiddle win32env.c to
support it; and I'm not sure back-patching such a change would be wise.

Alternatively, we could change secure_open_gssapi() to use putenv(),
at the cost of a couple more lines of code.

Thoughts?

regards, tom lane

[1] https://www.postgresql.org/message-id/SN2PR05MB264066382E2CC75E734492C8E3510%40SN2PR05MB2640.namprd05.prod.outlook.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-12-16 23:35:12 reducing memory usage by using "proxy" memory contexts?
Previous Message Thomas Munro 2019-12-16 23:17:08 Re: ERROR: could not resize shared memory segment...No space left on device