Mail Archives: cygwin/2010/12/29/01:34:52
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) http://cygwin.com/ml/cygwin/2004-11/msg00488.html
> 2) http://cygwin.com/ml/cygwin/2004-11/msg00513.html
>
>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.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -