From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 341 invoked by alias); 27 Feb 2011 04:23:05 -0000 Received: (qmail 32716 invoked by uid 22791); 27 Feb 2011 04:23:03 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from prod-mail-xrelay03.akamai.com (HELO prod-mail-xrelay03.akamai.com) (96.6.114.84) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 27 Feb 2011 04:22:58 +0000 Received: from prod-mail-xrelay03.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3D3EF3C4010; Sun, 27 Feb 2011 04:22:56 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (unknown [172.27.8.27]) by prod-mail-xrelay03.akamai.com (Postfix) with ESMTP id 271D93C400F; Sun, 27 Feb 2011 04:22:56 +0000 (UTC) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub3.kendall.corp.akamai.com [172.17.120.166]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 004FE47BD2; Sun, 27 Feb 2011 04:22:56 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.150]) by usma1ex-cashub3.kendall.corp.akamai.com ([::1]) with mapi; Sat, 26 Feb 2011 23:22:55 -0500 From: "Lubashev, Igor" To: "Ross.Johnson@homemail.com.au" CC: "pthreads-win32@sourceware.org" Date: Sun, 27 Feb 2011 04:23:00 -0000 Subject: Re: pthread.h is breaking programs that use strtok_r and rand_r Message-ID: <83CE6FF8F6C9B2468A618FC2C512672605AB94E0C2@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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/msg00013.txt.bz2 Thank you! - Igor Lubashev -----Original Message----- From: Ross Johnson [Ross.Johnson@homemail.com.au] Received: Saturday, 26 Feb 2011, 8:13pm To: Lubashev, Igor [ilubashe@akamai.com] CC: pthreads-win32@sourceware.org [pthreads-win32@sourceware.org] Subject: Re: pthread.h is breaking programs that use strtok_r and rand_r 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 bre= aking 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 p= rovide their definitions for these POSIX functions. Unfortunately, if pthr= ead.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) =3D strtok( (_s), (= _sep) ) ) > > It completely ignores _lasts field, which is not standard compliant. Sta= ndard requires: "Different strings may be parsed concurrently using sequenc= es 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[] =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, " "= ,&save2)); > return EXIT_SUCCESS; > } > > > The result is expected: "day and night" > > However, if I uncomment #include, the result is: "(null) and n= ight". > > --- 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 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 us= eful 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 add= ress. > > > > In general, it is a very bad form for pthread.h to define and drop into c= lient'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