From owner-freebsd-hackers  Thu Feb  2 09:03:37 1995
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA10150 for hackers-outgoing; Thu, 2 Feb 1995 09:03:37 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA10142; Thu, 2 Feb 1995 09:03:25 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA20356; Fri, 3 Feb 1995 03:57:23 +1100
Date: Fri, 3 Feb 1995 03:57:23 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199502021657.DAA20356@godzilla.zeta.org.au>
To: freebsd-bugs@freefall.cdrom.com, freebsd-hackers@freefall.cdrom.com,
        kurto@tiny.mcs.usu.edu, ponds!rivers@dg-rtp.dg.com
Subject: Re: drand48 problems persist.
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>Hi, I've seen this problem, in fact I think that I was the first to report it.
>And Bruce Evans sent my a description of what's going in a very short time
>after (for which I grateful.)  The situation is that drand48 isn't in some
>standard or another so it's not really wanted in the header files which
>are trying to be compliant.  So even though you've declared drand48 to
>return a double, libc was built with the assumption that it's an int,
>therefore when drand48 calls erand48 (also 'thought' to be int) some junk
>is left on the fp stack which then blows up later.

But this is fixed now (the header files aren't very standard :-).  The
test program works for me on freefall and at home even if it is linked
to the shared library on the 2.0 cdrom.

Bruce