bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mingw, ptw32, and struct timespec


From: Jim Meyering
Subject: Re: mingw, ptw32, and struct timespec
Date: Wed, 02 Jun 2010 20:15:16 +0200

Eric Blake wrote:

> On 06/02/2010 10:50 AM, Eric Blake wrote:
>> I'm getting a compilation failure when trying to cross-compile from
>> Linux to mingw, because I have the mingw pthreads-win32 (ptw32) library
>> installed (Fedora 13 system, with mingw32-pthreads and mingw32-gcc
>> packages).  The ptw32 library installs a pthread.h that blindly defines
>> struct timespec if HAVE_STRUCT_TIMESPEC is not defined:
>>
>> #ifndef HAVE_STRUCT_TIMESPEC
>> #define HAVE_STRUCT_TIMESPEC 1
>> struct timespec {
>>         long tv_sec;
>>         long tv_nsec;
>> };
>> #endif /* HAVE_STRUCT_TIMESPEC */
>>
>> That library also has the nasty behavior of installing a config.h file,
>> which it then includes as part of pthread.h (recommended practice is
>> that config.h must NEVER be installed, and that if you are installing a
>> public header that depends on configuration options, you should install
>> a header by a different name that only your package will refer to, and
>> that you should make an extreme effort to make the file be independent
>> of compiler options that might differ between when your library was
>> configured vs. when a client of your library is configured).
>
> It gets worse.  The ptw32 library pthread.h is broken, with unsafe
> constructs like:
>
> #define localtime_r( _clock, _result ) \
>         ( *(_result) = *localtime( (_clock) ), \
>           (_result) )
>
> that evaluate _result multiple times within the function call.  The
> complete list of broken *_r functions incorrectly defined in <pthread.h>:
>
> strtok_r
> asctime_r
> ctime_r
> gmtime_r
> localtime_r
> rand_r
>
> Maybe the better thing for gnulib to do would be to flat-out reject the
> ptw32 pthread.h as useless, until pthreads-win32 cleans up the mess?

That is harsh, but it sounds like the right approach.
These problems are too fundamental (and likely ephemeral)
to be worth an investment in gnulib work-around code.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]