Re: [PATCH] Bad timestamps on MinGW32

[Jeffrey Walton]

On Wed, Nov 2, 2022 at 4:15 PM Orgad Shaneh <orgads@gmail.com> wrote:
>
> On Wed, Nov 2, 2022 at 7:04 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > Fix by enabling _stat64 also for MinGW.
> >
> > Thanks, but this cannot be done for all MinGW builds.  There's
> > mingw.org's MinGW (which is what I use), and its default is to use
> > 32-bit time_t values.  If you use this change with that MinGW, Make
> > will likely crash at run time, because various libraries it is linked
> > against use a different time_t in stat calls.
>
> Hi, and thanks for the prompt reply.
>
> Do you mean that __MINGW_USE_VC2005_COMPAT has no effect on this
> platform? Or that it doesn't support _stat64? Or something else?
>
> > So this condition:
> >
> > > -#if defined(_MSC_VER) && _MSC_VER > 1200
> > > +#if defined(__MINGW32__) || (defined(_MSC_VER) && _MSC_VER > 1200)
> >
> > must be rewritten to catch only MinGW64 builds.  Which would mean a
> > more fine-grained testing of the value of __MINGW_MAJOR_VERSION etc.
>
> I'll try to find something. But first I'll need an answer for the
> previous question, so I know which changes to look for in mingw.

You might also be interested in __MINGW64__.

I don't think it's a good idea to try to use MinGW or compiler
versions as a proxy for 32- or 64-bit time_t. Things are in flux to
fix the y2038 problem. The debian-arm and debian-powerpc lists are
having discussions about it now. You will surely encounter 64-bit
time_t on 32-bit machines eventually.

A first class configure test that checks for the size of time_t will
probably be your best choice.

Jeff