public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* pthread.h is breaking programs that use strtok_r and rand_r
@ 2010-12-28 18:33 Lubashev, Igor
  2011-02-27  1:13 ` Ross Johnson
  0 siblings, 1 reply; 5+ messages in thread
From: Lubashev, Igor @ 2010-12-28 18:33 UTC (permalink / raw)
  To: pthreads-win32

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: pthread.h is breaking programs that use strtok_r and rand_r
  2010-12-28 18:33 pthread.h is breaking programs that use strtok_r and rand_r Lubashev, Igor
@ 2011-02-27  1:13 ` Ross Johnson
  2011-02-27  2:57   ` John E. Bossom
  0 siblings, 1 reply; 5+ messages in thread
From: Ross Johnson @ 2011-02-27  1:13 UTC (permalink / raw)
  To: Lubashev, Igor; +Cc: pthreads-win32

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: pthread.h is breaking programs that use strtok_r and rand_r
  2011-02-27  1:13 ` Ross Johnson
@ 2011-02-27  2:57   ` John E. Bossom
  2011-02-27  8:42     ` Ross Johnson
  0 siblings, 1 reply; 5+ messages in thread
From: John E. Bossom @ 2011-02-27  2:57 UTC (permalink / raw)
  To: pthreads-win32


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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: pthread.h is breaking programs that use strtok_r and rand_r
  2011-02-27  2:57   ` John E. Bossom
@ 2011-02-27  8:42     ` Ross Johnson
  0 siblings, 0 replies; 5+ messages in thread
From: Ross Johnson @ 2011-02-27  8:42 UTC (permalink / raw)
  To: John E. Bossom; +Cc: pthreads-win32

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: pthread.h is breaking programs that use strtok_r and rand_r
@ 2011-02-27  4:23 Lubashev, Igor
  0 siblings, 0 replies; 5+ messages in thread
From: Lubashev, Igor @ 2011-02-27  4:23 UTC (permalink / raw)
  To: Ross.Johnson; +Cc: pthreads-win32

Thank you!

- Igor Lubashev


-----Original Message-----
From: Ross Johnson [Ross.Johnson@homemail.com.au]
Received: Saturday, 26 Feb 2011, 8:13pm
To: Lubashev, Igor [ilubashe@akamai.com]
CC: pthreads-win32@sourceware.org [pthreads-win32@sourceware.org]
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-02-27  8:42 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-28 18:33 pthread.h is breaking programs that use strtok_r and rand_r Lubashev, Igor
2011-02-27  1:13 ` Ross Johnson
2011-02-27  2:57   ` John E. Bossom
2011-02-27  8:42     ` Ross Johnson
2011-02-27  4:23 Lubashev, Igor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).