Re: plpython vs _POSIX_C_SOURCE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: plpython vs _POSIX_C_SOURCE
Date: 2023-01-24 21:16:06
Message-ID: 2320614.1674594966@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> Python's _POSIX_C_SOURCE value is set to a specific value in their configure
> script:

> if test $define_xopen_source = yes
> then
> ...
> AC_DEFINE(_POSIX_C_SOURCE, 200809L, Define to activate features from IEEE Stds 1003.1-2008)
> fi

Hm. I looked into Python 3.2 (the oldest release we still support)
and it has similar code but

AC_DEFINE(_POSIX_C_SOURCE, 200112L, Define to activate features from IEEE Stds 1003.1-2001)

So yeah it's fixed (or else not defined) for any particular Python
release, but could vary across releases.

> Solaris and AIX are the ones missing.
> I guess I'll test them manually. It seems promising not to need this stuff
> anymore?

Given that hoverfly is AIX, I'm betting there's an issue there.

>> Anyway, I'm still of the opinion that what a11cf433413 tried to do
>> was the best available fix, and we need to do whatever we have to do
>> to plpython's headers to reinstate that coding rule.

> You think it's not a viable path to just remove the _POSIX_C_SOURCE,
> _XOPEN_SOURCE undefines?

I think at the least that will result in warnings on some platforms,
and at the worst in actual build problems. Maybe there are no more
of the latter a dozen years after the fact, but ...

>> That would be nice. This old code was certainly mostly concerned with
>> python 2, maybe python 3 no longer does that?

> There's currently no non-comment references to *printf in their headers. The
> only past reference was removed in:
> commit e822e37946f27c09953bb5733acf3b07c2db690f
> Author: Victor Stinner <vstinner(at)python(dot)org>
> Date: 2020-06-15 21:59:47 +0200
> bpo-36020: Remove snprintf macro in pyerrors.h (GH-20889)

Oh, interesting.

> Which suggests an easier fix would be to just to do

> /*
> * Python versions <= 3.8 otherwise define a replacement, causing
> * macro redefinition warnings.
> */
> #define HAVE_SNPRINTF

> And have that be enough for all python versions?

Nice idea. We did not have that option while we were using HAVE_SNPRINTF
ourselves, but now that we are not I concur that this should work.
(I confirmed that their code looks the same in Python 3.2.)
Note that you'd better make it

#define HAVE_SNPRINTF 1

or you risk macro-redefinition warnings.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2023-01-24 21:17:23 Re: heapgettup refactoring
Previous Message Andrew Dunstan 2023-01-24 21:11:20 Re: run pgindent on a regular basis / scripted manner