bright@nazgul.UUCP (Walter Bright) (02/24/91)
In article <LT5NQEC@methan.chemie.fu-berlin.de> 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);
/I have found that a statement such as
/ atof("");
/would help. Anyway, I think that this "feature" of TC is a nuisance.
In TC, the floating point library is only linked in if one of the OBJ files
for the program contained a floating point operation. This is nice because
if you don't use floating point you don't carry around the bulk of the library
code. The downside is this causes a significant burden on the tech support,
as 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. If you don't need it, then compile with -mi or link in the
INT.OBJ object module. The upside is we never get tech support calls like
the one above. The downside is many people never notice the -mi switch and
wind up thinking that ZTC generates unnaturally large EXE files. Even many
magazine reviewers have fallen into this error.
I'm all ears if anyone has a suggestion on how to get the best of both
by default.gwyn@smoke.brl.mil (Doug Gwyn) (02/26/91)
In article <268@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes: >I'm all ears if anyone has a suggestion on how to get the best of both >by default. 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, in a translation unit. Of course the system C library was set up so that a reference to "__fltused" caused the full format support to be linked rather than the usual integer-only format support object module. You could of course also have the compiler pay special attention to the format strings for *scanf() and *printf(), although that is not foolproof.
gwyn@smoke.brl.mil (Doug Gwyn) (02/26/91)
>In article <268@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes: >>I'm all ears if anyone has a suggestion on how to get the best of both >>by default. Another point I should have mentioned when responding to the above is that with shared libraries, there is no good reason not to simply always provide full format support.
scs@adam.mit.edu (Steve Summit) (02/26/91)
In article <268@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes: >In article <LT5NQEC@methan.chemie.fu-berlin.de> 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
harrison@necssd.NEC.COM (Mark Harrison) (02/27/91)
In article <268@nazgul.UUCP>, bright@nazgul.UUCP (Walter Bright) writes: > In TC, the floating point library is only linked in if one of the OBJ files > for the program contained a floating point operation. > In ZTC, we use the opposite approach. Floating point is always linked in > by default. If you don't need it, then compile with -mi or link in the > INT.OBJ object module. > I'm all ears if anyone has a suggestion on how to get the best of both > by default. Perhaps you could add some kind of informatory message at link time... "Linking floating point stuff, but don't see that you are using any floating point in your program... Use the -mi option if you don't want floating point." Of course, then you would need a linker option to suppress this message :-( -- Mark Harrison harrison@necssd.NEC.COM (214)518-5050 {necntc, cs.utexas.edu}!necssd!harrison standard disclaimers apply...
gwyn@smoke.brl.mil (Doug Gwyn) (02/27/91)
In article <1991Feb26.085503.14893@athena.mit.edu> scs@adam.mit.edu writes: >(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.) The latter, to accommodate subtle cases that could cause problems. Another thing I did, which so far as I know was unique to my variant of Ritchie's compiler, was to arrange that upon entry to a function that made any use of floating point (again relying on the "fltused" flag), after the stack pointer was adjusted to allow room for autos, I output a "TST (SP)" instruction. The point of this was to force a segmentation violation at that point, in cases where the stack had just been grown past the current maximum size, rather than later when a floating-point instruction might have triggered the segmentation violation trap. This was necessary on the PDP-11/34, which did not maintain enough state information to be able to successfully restart all floating-point instructions that could have caused such a trap. (Basically I had borrowed the PDP-11/45 UNIX instruction restart code and asynchronous floating-point processor support and folded it into the PDP-11/40 UNIX kernel. There were some subtle 11/40 vs. 11/34 differences that had to be addressed also.)
ts@cup.portal.com (Tim W Smith) (02/28/91)
Walter Bright writes:
< I'm all ears if anyone has a suggestion on how to get the best of both
< by default.
Here's a horrible kludge idea: if the linker is linking without the
floating point libraries, have it start over with them included if
a link error is encountered.
By the way, are you the same Walter Bright who used to be at Caltech?
Tim Smithbright@nazgul.UUCP (Walter Bright) (03/07/91)
In article <15316@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
/You could of course also have the compiler pay special attention to the
/format strings for *scanf() and *printf(), although that is not foolproof.
I think this would be a bug in the compiler for these reasons:
1. The format strings may not be available to the compiler, as they
may be built dynamically or be in another module.
2. The library is supposed to be independent of the compiler. Having the
compiler recognize these things could make it very problematical if
somebody rolled their own printf/scanf.henry@zoo.toronto.edu (Henry Spencer) (03/09/91)
In article <279@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes: >/You could of course also have the compiler pay special attention to the >/format strings for *scanf() and *printf(), although that is not foolproof. > >2. The library is supposed to be independent of the compiler... Nope; they are both part of the "implementation", and may well be heavily interdependent. Notably, it's very difficult to avoid interdependencies in longjmp(). > ... could make it very problematical if > somebody rolled their own printf/scanf. There is no portable way to do this anyway; ANSI C reserves all the standard-library identifiers and forbids redefinition. -- "But this *is* the simplified version | Henry Spencer @ U of Toronto Zoology for the general public." -S. Harris | henry@zoo.toronto.edu utzoo!henry
gwyn@smoke.brl.mil (Doug Gwyn) (03/11/91)
In article <279@nazgul.UUCP>, bright@nazgul.UUCP (Walter Bright) writes: - In article <15316@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: - /You could of course also have the compiler pay special attention to the - /format strings for *scanf() and *printf(), although that is not foolproof. - I think this would be a bug in the compiler for these reasons: - 1. The format strings may not be available to the compiler, as they - may be built dynamically or be in another module. - 2. The library is supposed to be independent of the compiler. Having the - compiler recognize these things could make it very problematical if - somebody rolled their own printf/scanf. 1. When string literals WERE used, the compiler would be free to use that fact. 2. A conforming hosted implementation includes library and language together; a strictly conforming program is NOT allowed to provide its own replacement for any of the standard library functions.
bright@nazgul.UUCP (Walter Bright) (03/12/91)
In article <39644@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: /Walter Bright writes: /< I'm all ears if anyone has a suggestion on how to get the best of both /< by default. /Here's a horrible kludge idea: if the linker is linking without the /floating point libraries, have it start over with them included if /a link error is encountered. The "Floating point not loaded" is a runtime error message, not a link time message. /By the way, are you the same Walter Bright who used to be at Caltech? I attended Caltech from 1975-79. / Tim Smith I remember you too!
bright@nazgul.UUCP (Walter Bright) (03/22/91)
In article <15406@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <279@nazgul.UUCP>, bright@nazgul.UUCP (Walter Bright) writes: >- In article <15316@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >- /You could of course also have the compiler pay special attention to the >- /format strings for *scanf() and *printf(), although that is not foolproof. >- I think this would be a bug in the compiler for these reasons: >- 1. The format strings may not be available to the compiler, as they >- may be built dynamically or be in another module. >- 2. The library is supposed to be independent of the compiler. Having the >- compiler recognize these things could make it very problematical if >- somebody rolled their own printf/scanf. > >1. When string literals WERE used, the compiler would be free to use >that fact. True. My only concern about this is a complexity issue, the more complicated the rules are, the more confusing it is to understand why one piece of source works and the other doesn't. I prefer simple rules that work 95% of the time to complex rules that work 97% of the time... :-) >2. A conforming hosted implementation includes library and language >together; a strictly conforming program is NOT allowed to provide its >own replacement for any of the standard library functions. Also very true. But it is also true that we have a lot of customers who are not particularly interested in writing strictly conforming programs. You should see the number of requests we get for supporting // comments in the C compiler! People know it's not standard C, but they want to use it. (It will be in the next version!) One of the great strengths of C is its ability to be bent to the customer's needs. I had a very bad experience with Pascal (many years ago, before I discovered C). It seems most of my time spent debugging was trying to figure out how to get the Pascal built-in I/O to do what I needed. It was always too clever, doing things like converting all non-graphic characters into spaces before output! So much for trying to write to an ANSI terminal control sequences. Tabs were always converted to spaces... It wasn't a 'smart' system, it was a 'smart-ass' system. When I found C, and the I/O was independent of the compiler, I was sold. This experience causes me to view with a lot of distrust any attempts at building I/O into the compiler.