baldwin@usna.NAVY.MIL (J.D. Baldwin.) (10/11/90)
OK, I don't want to jump the gun and call this a "compiler bug" just yet,
but I'm mighty stumped by the following code (this is as simple as I can
make the example without the bug disappearing):
-------Cut here---------
#include <stdio.h>
#include <stdlib.h>
double * ar_1;
double x;
void main(void)
{
ar_1 = (double *) calloc(1, sizeof(double));
fflush(stdin);
/* scanf("%lf", &x); */
scanf("%lf", &(ar_1[0]));
printf("%lf\n", ar_1[0]);
}
-------Cut here---------
Here's the problem: when I compile and run this code under Turbo C 2.01, it
works fine--accepts a floating-point number and prints it out. When I
compile and run the SAME code under Turbo C++ 1.00, I hit the (uncommented)
scanf and get the following message:
scanf : floating point formats not linked
Abnormal program termination
It does not pause to get input before delivering this message.
Now it gets weird: I uncomment the first "scanf" call. Still works as
advertised under Turbo C 2.01--this time gets two doubles, and throws the
first one away. Now it works the same way under Turbo C++ 1.00 also!
If, instead of calloc-ating ar_1, I declare it as double ar_1[10], and get
rid of the calloc() line, it works the way it's supposed to in both compilers
(whether or not the extraneous scanf() is present).
I've tried setting and unsetting every possible compiler option--especially
the ones about making use of a 80287 co-processor (I have one) or FP
emulation, 8086 or 80286 code, etc., etc. I am running a Zenith Z-248
(AT compatible) and Zenith DOS 3.3 "plus." Of course I can get around
this problem by scanning in a temporary variable and re-assigning it,
but I'd rather understand what the heck's going on here!
I'd appreciate any help. If posted, I'll see it (I check all these groups--
and please note the followup redirection); if e-mailed, I'll echo it back to
the net. Thanks in advance.
--
From the catapult of: |+| "If anyone disagrees with anything I
_, J. D. Baldwin, Comp Sci Dept |+| say, I am quite prepared not only to
__||____:::)=}- U.S. Naval Academy|+| retract it, but also to deny under
\ / baldwin@cad.usna.navy.mil |+| oath that I ever said it." --T. Lehrer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~baldwin@usna.NAVY.MIL (J.D. Baldwin.) (10/11/90)
In article <344@usna.NAVY.MIL> I, with brain engaged firmly in neutral, wrote: [a bunch of code and text describing a problem in which] > > scanf("%lf", &(ar_1[0])); [resulted in] > > scanf : floating point formats not linked > Abnormal program termination Within hours, several people from across the nation answered me with "Yeah! I got something like that, too! I dunno why." This makes me feel much better--I wasn't the only one who hadn't read the FAQ list thoroughly recently. It took a Mr. Karl Heuer, of Interactive Systems, Cambridge, MA to set me straight by quoting, of all things, the FAQ list. The perceptive Mr. Heuer clearly knew that I must feel like a buffoon and kindly did not dwell on my error. I really *do* read these things. I swear. This one got by me. It's worth repeating here for those others (and now I know you're out there): >65. I'm having trouble with a Turbo C program which crashes and says > something like "floating point not loaded." > >A: Some compilers for small machines, including Turbo C and Ritchie's > original pdp11 compiler, attempt to leave out floating point support > if it looks like it will not be needed. In particular, the non- > floating-point versions of printf and scanf save space by not > including code to handle %e, %f, and %g. Occasionally the > heuristics for "is the program using floating point?" are > insufficient, and the programmer must insert one dummy explicit > floating-point operation to force loading of floating-point support. > Unfortunately, an apparently common sort of program (thus the > frequency of the question) uses scanf to read, and/or printf to > print, floating-point values upon which no arithmetic is done, which > elicits the problem under Turbo C. > > In general, questions about a particular compiler are inappropriate > for comp.lang.c . Problems with PC compilers, for instance, will > find a more receptive audience in a PC newsgroup. Apologies to the net. Thanks to Mr. Heuer. -- From the catapult of: |+| "If anyone disagrees with anything I _, J. D. Baldwin, Comp Sci Dept |+| say, I am quite prepared not only to __||____:::)=}- U.S. Naval Academy|+| retract it, but also to deny under \ / baldwin@cad.usna.navy.mil |+| oath that I ever said it." --T. Lehrer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AHB3@Lehigh (10/16/90)
The problem is a bug. Pure and simple. I have heard that Turbo C 1.0
had the same problem. What is happening is the compiler doesn't
realize that the variable being passed in is a floating point number,
so it don't link in the floating point routines to scanf. When you
uncomment the first scanf line, the compiler links the floating point
routines into scanf. If you didn't know, the compiler doesn't know
that the scanf routine will try to print a floating point number.
Only scanf knows. The format string used by scanf is just a string to
the compiler. Therefore, until they fix the bug (again), people will
have to use temporary variables for floats and doubles.
Arthur H. Boyd
Lehigh U.silver@xrtll.uucp (Hi Ho Silver) (10/20/90)
In article <15109018:58:51AHB3@lehigh.bitnet> AHB3@Lehigh writes:
$the compiler. Therefore, until they fix the bug (again), people will
$have to use temporary variables for floats and doubles.
Or you put a statement like
exp(1);
somewhere in your program. This will cause floating point library code
to be linked in.
--
HI ROGER |Nikebo says "Nikebo knows how to post. Just do it."| silver@xrtll
_________|-----------------------|_______________|------------|_____________
yunexus!xrtll!silver (L, not 1) | Hi Ho Silver | costing the net thousands
Silver: Ever Searching for SNTF |i need a grilf | upon thousands of dollars