f77 disallows floating point constants less than -2.59e+33
donn at sdchema.UUCP
donn at sdchema.UUCP
Fri Apr 13 16:56:18 AEST 1984
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
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list