Re: thread-safety: gmtime_r(), localtime_r()

On 19.08.24 11:43, Peter Eisentraut wrote:
> On 16.08.24 23:01, Thomas Munro wrote:
>> On Sat, Aug 17, 2024 at 3:43 AM Peter 
>> Eisentraut<peter@eisentraut.org>  wrote:
>>> I moved the _POSIX_C_SOURCE definition for MinGW from the header file to
>>> a command-line option (-D_POSIX_C_SOURCE).  This matches the treatment
>>> of _GNU_SOURCE and similar.
>> I was trying to figure out what else -D_POSIX_C_SOURCE does to MinGW.
>> Enables __USE_MINGW_ANSI_STDIO, apparently, but I don't know if we
>> were using that already, or if it matters.  I suppose if it ever shows
>> up as a problem, we can explicitly disable it.
>>
>> . o O ( MinGW is a strange beast.  Do we want to try to keep the code
>> it runs as close as possible to what is used by MSVC?  I thought so,
>> but we can't always do that due to missing interfaces (though I
>> suspect that many #ifdef _MSC_VER tests are based on ancient versions
>> and now bogus).  But it also offers ways to be more POSIX-y if we
>> want, and then we have to decide whether to take them, and make it
>> more like a separate platform with different quirks... )
> 
> Yeah, ideally we'd keep it aligned with MSVC.  But a problem here is 
> that if _POSIX_C_SOURCE (or _GNU_SOURCE or something like that) gets 
> defined for other reasons, then there would be conflicts between the 
> system headers and our workaround #define's.  At least plpython triggers 
> such a conflict in my testing.  This is the usual problem that we also 
> have with _GNU_SOURCE in other contexts.

I have committed this, with this amended explanation.