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

[Keith M. <kei...@us...>]

On 17/01/15 14:31, Eli Zaretskii wrote:
> This is just to draw people's attention to one issue I've bumped into
> with the latest MinGW runtime v3.21.
> 
> The runtime now defines 'struct timespec' in an internal header
> parts/time.h which is included by unistd.h, presumably to be able to
> declare a prototype of 'nanosleep'.

Exactly so, yes, (and this is the only use currently made of struct
timespec, within mingwrt).

> There are 2 problems with this:
> 
>  . 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.

>  . 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.

>    this means potential trouble, at least in the following cases:
> 
>    . if the replacement definition, generated as result of the failure
>      of the configure script to find the definition provided by MinGW,
>      uses time_t, and the application then includes unistd.h, the
>      compilation will fail; for one such problem that already happened
>      see
>        http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00042.html
> 
>    . including pthread.h in a program that also includes unistd.h will
>      most probably also fail, since pthread.h defines this structure
>      using time_t
> 
> I think MinGW should at least include parts/time.h in time.h.

Yes, eventually it should, and will.

> 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.  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.

-- 
Regards,
Keith.