pthread.h is breaking programs that use strtok_r and rand_r

[Ross Johnson]

Happy to be corrected. Good to see someone is still counting accurately :-)

On 27/02/2011 1:56 PM, John E. Bossom wrote:
>
> 1998!
>
>
> Quoting Ross Johnson <Ross.Johnson@homemail.com.au>:
>
>> They may have been much more useful back in 1996 however I've removed
>> them from the current CVS trunk.
>>
>> rand_r was used in two tests.
>>
>> Thanks.
>>
>> On 29/12/2010 5:33 AM, Lubashev, Igor wrote:
>>> Hi!
>>>
>>> First of all, thanks for a great project!
>>>
>>> I do have some issues to report, though.
>>>
>>> Header pthread.h is expected to be included by client code, but it  
>>> is breaking client code that uses strtok_r and rand_r.  Yes, these  
>>> macros are not defined on Windows, but people trying to write  
>>> portable code will likely provide their definitions for these POSIX 
>>>  functions.  Unfortunately, if pthread.h is included after the  
>>> headers providing these definitions, pthread.h will break client  
>>> code.  The definitions for these macros in pthread.h are not  
>>> standard compliant.
>>>
>>> 1.  pthread.h's definition for strtok_r:
>>>
>>>    #define strtok_r( _s, _sep, _lasts )  ( *(_lasts) = strtok(  
>>> (_s), (_sep) ) )
>>>
>>> It completely ignores _lasts field, which is not standard  
>>> compliant.  Standard requires: "Different strings may be parsed  
>>> concurrently using sequences of calls to strtok_r() that specify  
>>> different saveptr arguments."
>>>
>>>
>>> --- Test program on Windows:
>>>
>>> #include<stdio.h>
>>> #include<stdlib.h>
>>> #include<string.h>
>>>
>>> #define strtok_r strtok_s
>>>
>>> /* #include<pthread.h>  */
>>>
>>> int main(void)
>>> {
>>>   char str1[] = "A day";
>>>   char str2[] = "A night";
>>>   char *save1, *save2;
>>>   strtok_r(str1, "  ",&save1);
>>>   strtok_r(str2, "  ",&save2);
>>>   printf("%s and %s\n", strtok_r(NULL, "  ",&save1), strtok_r(NULL, 
>>>  " ",&save2));
>>>   return EXIT_SUCCESS;
>>> }
>>>
>>>
>>> The result is expected:  "day and night"
>>>
>>> However, if I uncomment #include<pthread.h>, the result is: "(null) 
>>>  and night".
>>>
>>> --- Note:
>>>
>>> Windows already has a compatible function called strtok_s.
>>>
>>> #define strtok_r strtok_s
>>>
>>>
>>>
>>> 2.  pthread.h's definition for rand_r:
>>>
>>>   #define rand_r( _seed ) ( _seed == _seed ? rand() : rand() )
>>>
>>> It completely ignores the _seed.  The standard requires rand_r to  
>>> use its seed as its state.  User code can rely on a deterministic  
>>> initial seed to receive a deterministic sequence of pseudo-random  
>>> numbers.  This is very useful in debugging, for example.  Moreover, 
>>>  rand_r output is not supposed to affect or be affected by calls to 
>>>  rand or rand_r with a different seed address.
>>>
>>>
>>>
>>> In general, it is a very bad form for pthread.h to define and drop  
>>> into client's global scope macros that are not related to pthreads  
>>> and are likely to collide on names with client's own macros or  
>>> functions.
>>>
>>> I hope the next release of pthread-win32 will address these issues.
>>>
>>>
>>> Cheers,
>>>
>>> - Igor Lubashev
>
>