From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16958 invoked by alias); 27 Feb 2011 08:42:37 -0000 Received: (qmail 16949 invoked by uid 22791); 27 Feb 2011 08:42:37 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from flexo.grapevine.net.au (HELO flexo.grapevine.net.au) (203.129.32.140) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 27 Feb 2011 08:42:29 +0000 Received: from localhost (localhost [127.0.0.1]) by flexo.grapevine.net.au (Postfix) with ESMTP id 5858A5E857B; Sun, 27 Feb 2011 19:42:27 +1100 (EST) Received: from flexo.grapevine.net.au ([127.0.0.1]) by localhost (flexo.grapevine.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVlASQs6rgUS; Sun, 27 Feb 2011 19:42:27 +1100 (EST) Received: from [192.168.2.2] (ppp-44-41.grapevine.net.au [203.129.44.41]) (Authenticated sender: Ross.Johnson@homemail.com.au) by flexo.grapevine.net.au (Postfix) with ESMTPA id 097B15E807C; Sun, 27 Feb 2011 19:42:26 +1100 (EST) Message-ID: <4D6A0E66.5010608@homemail.com.au> Date: Sun, 27 Feb 2011 08:42:00 -0000 From: Ross Johnson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "John E. Bossom" CC: pthreads-win32@sourceware.org Subject: Re: pthread.h is breaking programs that use strtok_r and rand_r References: <83CE6FF8F6C9B2468A618FC2C512672605A0446E29@USMBX1.msg.corp.akamai.com> <4D69A52B.3030507@homemail.com.au> <20110226215651.6u0yn6o7wwoo4ss0@webmail.pioneerwireless.ca> In-Reply-To: <20110226215651.6u0yn6o7wwoo4ss0@webmail.pioneerwireless.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2011/txt/msg00014.txt.bz2 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 : > >> 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 >>> #include >>> #include >>> >>> #define strtok_r strtok_s >>> >>> /* #include */ >>> >>> 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, 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 > >