Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!yale!decvax!decwrl!amdcad!cae780!gordon
From: gordon@cae780.UUCP
Newsgroups: net.decus,net.unix
Subject: (VMS) HUGE > (4.3bsd) HUGE
Message-ID: <2552@cae780.UUCP>
Date: Tue, 12-Aug-86 13:58:07 EDT
Article-I.D.: cae780.2552
Posted: Tue Aug 12 13:58:07 1986
Date-Received: Thu, 14-Aug-86 06:03:06 EDT
Organization: Tektronix, Inc. (CAE Systems Division), Santa Clara, CA
Lines: 34
Xref: mnetor net.decus:371 net.unix:5189

Chasing a wierd bug in portable code led to the following discovery -
the hex representatation of HUGE (from math.h) is
	0xffff7fffffffffff	under VMS (4.4, C 2.2)
	0xffff7ffffffffff0	under 4.3bsd

The effect of this difference shows up as follows:
	double d;
	float f;

	f = HUGE;	/* Compile time error under VMS, fine under 4.3bsd */
	f = (float) HUGE;	/* ditto */

	d = HUGE;
	f = d;	/* Run time error under VMS, fine under 4.3bsd */
	f = (float) d; /* ditto */

The HUGE of VMS is, of course, larger than the biggest value you can fit
into a float, since the exponent is the same and the fraction is a tad
larger.  The same is true under 4.3bsd, but the difference is less.
Apparently the double -> float conversion tries to round, and one version
of HUGE is roundable while the other is not.  Of course, the VMS version
is "right", since that IS the largest double possible, and the 4.3bsd
version is "wrong", since bigger doubles are possible -- but it is also a
useful float value.  Both values are 1.701411...e38.

Does the user community consider this a bug or a feature?  If so, WHICH is
the bug?  Or is the mismatch a bug?  Or ..

FROM:   Brian G. Gordon, CAE Systems Division of Tektronix, Inc.
UUCP:   tektronix!cae780!gordon
	{ihnp4, decvax!decwrl}!amdcad!cae780!gordon 
        {hplabs, resonex, qubix, leadsv}!cae780!gordon 
USNAIL: 5302 Betsy Ross Drive/#58137, Santa Clara, CA  95052-8137
AT&T:   (408)748-4817 [direct]    (408)727-1234 [switchboard]