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

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

On 20/01/15 16:47, Eli Zaretskii wrote:
>> Date: Tue, 20 Jan 2015 08:52:46 +0000
>> From: Keith Marshall
>> 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?

It needs a review of time.h, vis-a-vis other existing headers; is there
anything else in there which should maybe be factored out, into the
internal header.  ATM, I simply cannot devote any time to this.

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

But we have always instructed users to seek documentation on MSDN; this
would now have them believe that time_t defaults to 64-bit.

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

The Q&D patch I suggested yesterday would also *remove* nanosleep() from
libmingwex() entirely, so no, a configure script would not find it in a
quickly republished mingwrt-3.21.1.

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

In an ideal world, I agree.  However, current constraints on my time
mean that I may not be able to address that effectively until July or
August, at the earliest, whereas I might just manage to squeeze out a
Q&D interim release, with nanosleep() removed.

-- 
Regards,
Keith.