This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: drand48() (and erand48) returns only zeros and pthread application problems

On Wed, Dec 29, 2010 at 03:47:42AM +0100, Jorge D?az wrote:
>I am working with cygwin environment (Cygwin 1.7.7 + Newlib 1.18)
>where drand48 function returns always zero values.
>The problem was reported in 2004 at cygwin mailist:
>    1)
>    2)
>It seems the problem is at drand48 internal initialization. As a
>workaround if srand48 is called at program beginning, future drand48
>calls works ok, but this srand48 call is not mandatory.
>A main problem related with drand48 returning only zeros are cygwin
>pthread applications that uses drand48:
>1) We execute srand48 initialization as a workaround of drand48
>problems in main function.
>2) After this, if we create several threads, the new threads created
>in application, has the same zeros problem, but we called srand48 in
>main function.
>The application behavior in Cygwin is like every thread has its own
>"srand48, drand48 and erand48" internal environment and the generated
>numbers are isolated. In linux and solaris, generated numbers are
>mixed between all threads.

That is exactly what is happening but, as I noted in the above discussion,
this behavior is a bug.

I've implemented a workaround which will show up in the next snapshot.
But, perhaps someone will want to figure out what's wrong with newlib and
implement a real fix.

I see that freebsd doesn't have this problem so, since that is the code
base from which the *48 functions are derived, maybe this has actually
been fixed and newlib could benefit from that.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]