pthread.h is breaking programs that use strtok_r and rand_r

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

pthread.h is breaking programs that use strtok_r and rand_r

Lubashev, Igor
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
Reply | Threaded
Open this post in threaded view
|

Re: pthread.h is breaking programs that use strtok_r and rand_r

Ross Johnson-2
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

Reply | Threaded
Open this post in threaded view
|

Re: pthread.h is breaking programs that use strtok_r and rand_r

John Bossom

1998!


Quoting Ross Johnson <[hidden email]>:

> 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


Reply | Threaded
Open this post in threaded view
|

Re: pthread.h is breaking programs that use strtok_r and rand_r

Lubashev, Igor
In reply to this post by Lubashev, Igor
Thank you!

- Igor Lubashev


-----Original Message-----
From: Ross Johnson [[hidden email]]
Received: Saturday, 26 Feb 2011, 8:13pm
To: Lubashev, Igor [[hidden email]]
CC: [hidden email] [[hidden email]]
Subject: Re: pthread.h is breaking programs that use strtok_r and rand_r



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

Reply | Threaded
Open this post in threaded view
|

Re: pthread.h is breaking programs that use strtok_r and rand_r

Ross Johnson-2
In reply to this post by John Bossom
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 <[hidden email]>:
>
>> 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
>
>