From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3028 invoked by alias); 27 Feb 2011 02:57:00 -0000 Received: (qmail 3020 invoked by uid 22791); 27 Feb 2011 02:56:59 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from s194.n227.n6.n64.static.myhostcenter.com (HELO pioneerwireless.ca) (64.6.227.194) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 27 Feb 2011 02:56:53 +0000 Received: (qmail 16009 invoked by uid 48); 26 Feb 2011 21:56:51 -0500 Received: from cable97-30.sudbury.personainc.net (cable97-30.sudbury.personainc.net [216.104.97.30]) by webmail.pioneerwireless.ca (Horde MIME library) with HTTP; Sat, 26 Feb 2011 21:56:51 -0500 Message-ID: <20110226215651.6u0yn6o7wwoo4ss0@webmail.pioneerwireless.ca> Date: Sun, 27 Feb 2011 02:57:00 -0000 From: "John E. Bossom" To: 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> In-Reply-To: <4D69A52B.3030507@homemail.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) 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/msg00012.txt.bz2 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=20=20= =20 >> is breaking client code that uses strtok_r and rand_r. Yes, these=20=20= =20 >> macros are not defined on Windows, but people trying to write=20=20=20 >> portable code will likely provide their definitions for these POSIX=20=20 >> functions. Unfortunately, if pthread.h is included after the=20=20=20 >> headers providing these definitions, pthread.h will break client=20=20=20 >> code. The definitions for these macros in pthread.h are not=20=20=20 >> standard compliant. >> >> 1. pthread.h's definition for strtok_r: >> >> #define strtok_r( _s, _sep, _lasts ) ( *(_lasts) =3D strtok(=20=20=20 >> (_s), (_sep) ) ) >> >> It completely ignores _lasts field, which is not standard=20=20=20 >> compliant. Standard requires: "Different strings may be parsed=20=20=20 >> concurrently using sequences of calls to strtok_r() that specify=20=20=20 >> different saveptr arguments." >> >> >> --- Test program on Windows: >> >> #include >> #include >> #include >> >> #define strtok_r strtok_s >> >> /* #include */ >> >> int main(void) >> { >> char str1[] =3D "A day"; >> char str2[] =3D "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,=20=20 >> " ",&save2)); >> return EXIT_SUCCESS; >> } >> >> >> The result is expected: "day and night" >> >> However, if I uncomment #include, the result is: "(null)=20=20 >> 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 =3D=3D _seed ? rand() : rand() ) >> >> It completely ignores the _seed. The standard requires rand_r to=20=20= =20 >> use its seed as its state. User code can rely on a deterministic=20=20= =20 >> initial seed to receive a deterministic sequence of pseudo-random=20=20= =20 >> numbers. This is very useful in debugging, for example. Moreover,=20=20 >> rand_r output is not supposed to affect or be affected by calls to=20=20 >> rand or rand_r with a different seed address. >> >> >> >> In general, it is a very bad form for pthread.h to define and drop=20=20= =20 >> into client's global scope macros that are not related to pthreads=20=20= =20 >> and are likely to collide on names with client's own macros or=20=20=20 >> functions. >> >> I hope the next release of pthread-win32 will address these issues. >> >> >> Cheers, >> >> - Igor Lubashev