public inbox for
 help / color / mirror / Atom feed
From: "Lubashev, Igor" <>
To: "" <>
Subject: pthread.h is breaking programs that use strtok_r and rand_r
Date: Tue, 28 Dec 2010 18:33:00 -0000	[thread overview]
Message-ID: <> (raw)


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.


- Igor Lubashev

             reply	other threads:[~2010-12-28 18:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-28 18:33 Lubashev, Igor [this message]
2011-02-27  1:13 ` Ross Johnson
2011-02-27  2:57   ` John E. Bossom
2011-02-27  8:42     ` Ross Johnson
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

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