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