From owner-freebsd-hackers  Wed Feb  1 23:41:42 1995
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id XAA19895 for hackers-outgoing; Wed, 1 Feb 1995 23:41:42 -0800
Received: from tiny.mcs.usu.edu (tiny.mcs.usu.edu [129.123.15.8]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id XAA19889; Wed, 1 Feb 1995 23:41:40 -0800
Received: by tiny.mcs.usu.edu (8.6.8/1.34)
	id BAA14026; Thu, 2 Feb 1995 01:45:07 -0700
Date: Thu, 2 Feb 1995 01:45:07 -0700
From: kurto@tiny.mcs.usu.edu (Kurt Olsen)
Message-Id: <199502020845.BAA14026@tiny.mcs.usu.edu>
To: freebsd-bugs@freefall.cdrom.com, freebsd-hackers@freefall.cdrom.com,
        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.

A prototype has been placed into stdlib.h, but it's ifdef-ed out requiring
the inclusion of #define POSIXGOBBLEDEEGOOK (or something.)  However I don't
beleive this is defined during the libc build so even though it's in the
headers it won't work unless you can rebuild libc (which unfortunately I
don't have the knowledge, experience or diskspace to do.)

Kurt Olsen
kurto@tiny.mcs.usu.edu