From: Ross Johnson <Ross.Johnson@homemail.com.au>
To: "John E. Bossom" <drifting@pioneerwireless.ca>
Cc: pthreads-win32@sourceware.org
Subject: Re: pthread.h is breaking programs that use strtok_r and rand_r
Date: Sun, 27 Feb 2011 08:42:00 -0000 [thread overview]
Message-ID: <4D6A0E66.5010608@homemail.com.au> (raw)
In-Reply-To: <20110226215651.6u0yn6o7wwoo4ss0@webmail.pioneerwireless.ca>
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
>
>
next prev parent reply other threads:[~2011-02-27 8:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-28 18:33 Lubashev, Igor
2011-02-27 1:13 ` Ross Johnson
2011-02-27 2:57 ` John E. Bossom
2011-02-27 8:42 ` Ross Johnson [this message]
2011-02-27 4:23 Lubashev, Igor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D6A0E66.5010608@homemail.com.au \
--to=ross.johnson@homemail.com.au \
--cc=drifting@pioneerwireless.ca \
--cc=pthreads-win32@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).