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

On 16.08.24 23:01, Thomas Munro wrote:
> On Sat, Aug 17, 2024 at 3:43 AM Peter Eisentraut<peter(at)eisentraut(dot)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.