Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!shelby!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news From: scs@adam.mit.edu (Steve Summit) Newsgroups: comp.lang.c Subject: Re: TC++: "floating point formats not linked" Message-ID: <1991Feb26.085503.14893@athena.mit.edu> Date: 26 Feb 91 08:55:03 GMT References: <268@nazgul.UUCP> <15316@smoke.brl.mil> Sender: news@athena.mit.edu (News system) Reply-To: scs@adam.mit.edu Organization: Thermal Technologies, Inc. Lines: 94 In article <268@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes: >In article kirste@methan.chemie.fu-berlin.de (Burkhard Kirste) writes: >/>In TC++, running in "C" mode , the following code gives the error message: >/>"scanf: floating point formats not linked" >/>How do I link them? >/> float *w >/> fscanf(fp,"%f\n",w); >In TC, the floating point library is only linked in if one of the OBJ files >for the program contained a floating point operation. >...I have seen this one problem appearing over and over again for *years*. >In ZTC, we use the opposite approach. Floating point is always linked in >by default. >I'm all ears if anyone has a suggestion on how to get the best of both >by default. What puzzles me is why the solution -- which Doug has already mentioned -- is even mysterious. Walter is correct: the question does come up astonishingly frequently, and is covered in the comp.lang.c frequently-asked questions list even though it's a PC-specific question. The FAQ list entry used to say: Some compilers for small machines, including Turbo C and Ritchie's original PDP-11 compiler, attempt to leave out floating point support if it looks like it will not be needed. I reworded this when I realized that it seemed to place Ritchie's pdp11 compiler in the same class as Turbo C, although I never remembered the pdp11 compiler having anything like the problem so frequently reported for Turbo C. In article <15316@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >What I did when I maintained the Ritchie PDP-11 C compiler was to arrange >for the compiler to generate a reference to some symbol like "__fltused" >whenever there was ANY use of floating point, even simply a >declaration of a type whose base type was float or double... I just booted up my old pdp11, which as far as I know has a fairly vanilla V7 compiler, and for each of the fragments main() { double d; x(d); } and main() { double d; scanf("%lf", &d); printf("%f\n", d); } and extern char *malloc(); main() { double *dp = (double *)malloc(sizeof(double)); scanf("%lf", dp); printf("%f\n", *dp); } it spits out (in the assembly language output) the little handle .globl fltused which is the thing Doug referred to which forces loading of full floating-point support for things like printf and scanf. The only code I tried which didn't emit the ".globl fltused" was main() { double d; } and this program does so little with floating point (in fact, since nothing is done with the variable d, no code is generated at all except for a function prologue and ret statement), it probably won't miss the lack of floating-point printf formats. (Either my compiler is derived from the one Doug worked on after all, or his mods would have arranged for a fltused in this last case as well, which couldn't hurt.) As I recall, I once saw a pdp11 program fail because fltused had gotten confused, but it was due to some extremely obscure circumstances (which I couldn't possibly remember). Steve Summit scs@adam.mit.edu