Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: kenton@space.mit.edu (Kenton C. Phillips)
Newsgroups: comp.sys.sun
Subject: Lucky Numbers in SunOS 4.1
Keywords: SunOS
Message-ID: <1195@brchh104.bnr.ca>
Date: 11 Jan 91 18:10:25 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 54
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 10, Issue 12, message 4
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

The following numbers do not work with `cc` under SunOS 4.1 on
Sparcstations:

  0.00048428773880004882812500
  0.00774860382080078125000000
  0.12397766113281250000000000
  0.00040978193283081054687500
  0.00655651092529296875000000
  0.10490417480468750000000000

There may also be other numbers which are defective.  The below program
will demonstrate the problem:

main()
{
  double a;

  a = 0.00048428773880004882812500;  /* (or other evil number) */

  printf("%.16e\n",a);

  exit(0);
}

Perhaps this is not a severe problem, since there are many other numbers
to use which work perfectly well.  The binary representations for the
above numbers are

  0x3f3f 0xbd00 0x0000 0x0000
  0x3f7f 0xbd00 0x0000 0x0000
  0x3fbf 0xbd00 0x0000 0x0000
  0x3f3a 0xdb00 0x0000 0x0000
  0x3f7a 0xdb00 0x0000 0x0000
  0x3fba 0xdb00 0x0000 0x0000

Which might lead one to suspect a pattern.  This problem has been
demonstrated when the above program is compiled on Sparcs running SunOS
4.1.  The problem has not appeared when the compilation was done on Sparcs
running SunOS 4.0.3 or 4.1.1.

Under 4.1, `cc -S prog.c` generates the constant definition as

L2000000:     .word   0x3f69ffcc,0x0

rather than

L2000000:     .word   0x3f3fbd00,0x0

as it should.  It may be that the atof(3) routine is in error in SunOS 4.1.

Kenton C. Phillips
Computer Systems Manager
MIT Center for Space Research
kenton@space.mit.edu