TC++: "floating point formats not linked"

Steve Summit scs at adam.mit.edu
Tue Feb 26 19:55:03 AEST 1991


In article <268 at nazgul.UUCP> bright at nazgul.UUCP (Walter Bright) writes:
>In article <LT5NQEC at methan.chemie.fu-berlin.de> kirste at 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 at smoke.brl.mil> gwyn at 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 at adam.mit.edu



More information about the Comp.lang.c mailing list