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

["Lubashev, Igor" <ilubashe at akamai dot com>]

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