Re: plpython vs _POSIX_C_SOURCE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: plpython vs _POSIX_C_SOURCE
Date
Msg-id 2320614.1674594966@sss.pgh.pa.us
Whole thread Raw
In response to Re: plpython vs _POSIX_C_SOURCE  (Andres Freund <andres@anarazel.de>)
Responses Re: plpython vs _POSIX_C_SOURCE
List pgsql-hackers
Andres Freund <andres@anarazel.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@python.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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: run pgindent on a regular basis / scripted manner
Next
From: Melanie Plageman
Date:
Subject: Re: heapgettup refactoring