Re: [Mingw-users] Definition of struct timespec in MinGW runtime 3.21

[Eli Z. <el...@gn...>]

> Date: Tue, 20 Jan 2015 08:52:46 +0000
> From: Keith Marshall <kei...@us...>
> 
> >  . time.h does not include parts/time.h, although I think it was meant
> >    to do so.  As result, configure scripts that check whether system
> >    headers define the struct, and look for it in time.h and
> >    sys/time.h, will not find it.
> 
> I'll confess that I didn't think of possible third party ramifications,
> when I added struct timespec.  Yes, time.h should include parts/time.h,
> but I've yet to work through the details, and right now, I don't have
> time to address the issue.

Could you tell what potential problems need to be figured out for
this to happen?

> >  . The "usual" definition of 'struct timespec' uses time_t as the type
> >    of the tv_sec member, but MinGW runtime uses 'long long' instead.
> 
> But, what the heck is time_t?  As you well know, POSIX still thinks of
> it as 32-bit, but notes that it will eventually need to accommodate a
> wider numeric range than 32-bit can support; however, the POSIX working
> group has not yet given sufficient attention to how that might be
> accomplished to warrant standardization; Microsoft, OTOH, have shown us,
> dramatically, how to make a real pig's ear of it, with their utterly
> unworkable, and thoroughly ambiguous 32/64-bit implementation.
> 
> >    Since time_t is still 32-bit wide,
> 
> But is it?  Microsoft's _USE_32BIT_TIME_T insanity means that it could
> be either 32-bit or 64-bit.

Yes, I understand that.  I meant to say that MinGW's time_t is 32-bit
_by_default_.

> > Not sure what to do with the Pthreads incompatibility, though.  It
> > might be possible to add to parts/time.h the HAVE_STRUCT_TIMESPEC
> > guard that pthread.h uses to define its own struct, but that won't
> > help with using precompiled binaries of Pthreads, if they were built
> > with previous versions of MinGW.  Any suggestions?
> 
> With the benefit of hindsight -- isn't it a wonderful thing? -- perhaps
> I was premature in exposing the implementation of nanosleep(); I wanted
> to fix a broken usleep(), and nanosleep() was a natural extension of
> that resolution.  Obviously, *anything* which relies on time_t on
> Windows will be susceptible to 32 vs. 64-bit ambiguity in the typedef,
> and thus must be considered broken, so I contend that pthread.h is
> broken anyway.

I agree that this is not an easy problem.  But I think at least the
situation where one compiles the entire program, including any
3rd-party libraries, with the default mingwrt settings, where time_t
is a 32-bit quantity, should work.  Using time_t in struct timespec
thus would have solved more use cases than using 'long long'.  But I
guess this is water under the bridge, now that 3.21 is out in the
open.

> Since I don't have time to devote to this at present,
> perhaps the best interim solution would be to hide the nanosleep()
> implementation in unistd.h, thus making inclusion of parts/time.h
> unnecessary, (and parts/time.h redundant for the time being), until such
> time as a suitable resolution can be identified.

Hiding nanosleep will only help if the program doesn't use it.  If it
does, the configure script will likely find the function anyway
(because a test program will compile and link), and then using a
definition of 'struct timespec' supplied by, say, gnulib, with time_t
as the first member type, will produce a broken problem.

I think we should instead advertise our 'struct timespec' in time.h
ASAP, so that as many packages as possible detect its existence and
use our definition, instead of providing a (broken) substitute with
time_t.  (I already asked the gnulib maintainers to add a test for
unistd.h as one more possible place where 'struct timespec' might be
defined, and this change is already in upstream gnulib.)  This will
leave us with only Pthreads as a problem, where the solution is to
build the library with the latest MinGW runtime and change the struct
definition.

Thanks.