public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
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
>
>

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