[net.bugs.4bsd] f77 disallows floating point constants less than -2.59e+33

donn@sdchema.UUCP (04/13/84)

The distributed f77 will not accept floating point constants that are
smaller than roughly -2.59e33, but going by the representation one
would expect to be able to use constants as low as -1.70e38.  The
following program fails in the way shown:

---------------------------------------------------------------------------
% cat tst.f
	program tst

	real	s
	data	s	/-1.7e38/

	print *, s

	stop
	end
% f77 tst.f
tst.f:
   MAIN tst:
Error on line 4 of tst.f: data value too large

Error.  No assembly.
---------------------------------------------------------------------------

Positive floating point numbers up to 1.70e38 ARE allowed, however.
What's actually happened is that for some reason the minimum value
is set incorrectly in conv.c.  Here is the correction (notice that
the floating point numbers are given as bit patterns):

---------------------------------------------------------------------------
*** /tmp/,RCSt1004227	Fri Apr 13 01:34:35 1984
--- conv.c	Fri Apr 13 01:08:19 1984
***************
*** 21,27
  LOCAL long dminint[]  = { 0x0000d000, 0xffff00ff };
  
  LOCAL long dmaxreal[] = { 0xffff7fff, 0xffff7fff };
! LOCAL long dminreal[] = { 0x0000f800, 0xffffffff };
  
  ^L
  

--- 34,40 -----
  LOCAL long dminint[]  = { 0x0000d000, 0xffff00ff };
  
  LOCAL long dmaxreal[] = { 0xffff7fff, 0xffff7fff };
! LOCAL long dminreal[] = { 0xffffffff, 0xffff7fff };
  
  ^L
  
---------------------------------------------------------------------------

In case you're curious, the reason why the least significant bits are
not all ones is that an epsilon value was subtracted (added) in order
to detect overflow in atof(), which indicates overflow by returning the
maximum (minimum) floating point number.  This has the side effect that
you can't indicate the highest and lowest DOUBLE PRECISION numbers to
the precision of the representation, but this is not likely to hurt
anyone (famous last words).

Bob Corbett tells me that this fix was applied at Berkeley back on Dec.
13 of last year, so if you have a distribution more recent than that
you should ignore this article.  Thanks to Mike Brown at the National
Solar Observatory (kpno!brown) for pointing this bug out to me.

Donn Seeley    UCSD Chemistry Dept.       ucbvax!sdcsvax!sdchema!donn