Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (04/05/90)
One of the known bugs in TC 2.0 is that linking in printf() or scanf() or any of their variants will not necessarily cause the FP code to be linked in. The simplest solution is to include some dummy mathematical operation such as `x *= 1.0;' in your code which will cause the FP routines to be referenced.
pnl@hpfinote.HP.COM (Peter Lim) (04/07/90)
This brings back old memory of bugs in Turbo C 1.0. Some of the bugs
were outright silly (and shouldn't be there in the first place). They
were so silly that Borland refuse to acknowledge their existence !
In fact, Borland quietly release a second version 1.0 and fixed those
bugs without telling anybody !! This is for real ! I might still have
a copy of the original buggy version 1.0 sitting somewhere !
One of the most famous bug was the floating point division which gives
wrong results ! Can't remember the exact detail though .....
Human memory ...... its like flaky hard disk ..... :-(.
Regards, ## Life is fast enough as it is ........
Peter Lim. ## .... DON'T PUSH IT !! >>>-------,
########################################### :
E-mail: plim@hpsgwg.HP.COM Snail-mail: Hewlett Packard Singapore, :
Tel: (065)-279-2289 (ICDS, ICS) |
Telnet: 520-2289 1150 Depot Road, __\@/__
... also at: pnl@hpfipnl.HP.COM Singapore 0410. SPLAT !lwh@harpsichord.cis.ohio-state.edu (Loyde W. Hales II) (04/09/90)
>In article <1316@taurus.BITNET> <dorfman%math.tau.ac.il@CUNYVM.CUNY.EDU> >writes: >Here is a strange bug I discovered while porting a C source from MSC 4.0 >to the TURBO C 2.0 compiler. After "minimizing" the source, I ended up with >the following: >main() > { > static float matrix[3][3]; > int i=0; > scanf ("%f",&matrix[i][0]); > scanf ("%f",&matrix[0][0]); /* delte this line and the program crashes */ > } >The program works fine with both scanf's intact, but crashes when the >second one is deleted (???). After experimenting with it, I came to the >conclusion, that TURBO doesn't like something about the first scanf. >The message I get during run-time is: > scanf : floating point formats not linked >Abnormal program termination >It's interesting, how the floating point formats become (suddenly) >linked after the program is modified :-) >Does anyone know, > a) What's wrong with the 1st scanf (form TURBO's point of view) ? > b) What's causing the strange bug? > c) How can I use the 1st scanf without having to "invent" the second? The problem is, in a sense, with Turbo C; but it is documented. Turbo C, as with many C compilers, provides a Floating Point Emulator for those without a math co-processor (or wanting code portable to such machines). To make your executable smaller and compile/load sequences quicker, Turbo C checks tries to determine if you _really_use_floats_ before it will load the emulator. Well, they want to be a little brighter than just looking to see if the keyword ``float'' or ``double'' appear anywhere. (To be honest, I'm not certain why. I can come up with cases where I might use (float *) without wanting a float, but not ones that aren't bloody contrived.) Simply, it is not catching that this is a float, not a pointer to a float. Fixes: 1. Put any direct operation on a simple float anywhere in the code. E.g., float a = 0.0; 2. Check you manual. There is a fix suggested in Turbo C 2.0. I can't remember what it is, but there is an environment variable you can set to make floating-point libraries always load. I think there is also a compiler option for this. -=- Department of Computer and Information Science Loyde W. Hales, II The Ohio State University lwh@cis.ohio-state.edu 2036 Neil Avenue Mall, Columbus, Ohio 43201
leoh@hardy.hdw.csd.harris.com (Leo Hinds) (04/10/90)
In article <15080003@hpfinote.HP.COM> pnl@hpfinote.HP.COM (Peter Lim) writes: > >This brings back old memory of bugs in Turbo C 1.0. <text deleted> >One of the most famous bug was the floating point division which gives >wrong results ! Can't remember the exact detail though ..... I remember this one :-) ... the results I was getting were quite flakey, so I reduced the test to a=3/4 (in TC1.0, a=1.333) and b=4/3 (in TC1.0, b=.75) ... nothing like a free inversion! leoh@hdw.csd.harris.com Leo Hinds (305)973-5229 Gfx ... gfx ... :-) whfg orpnhfr V "ebg"grq zl fvtangher svyr lbh guvax V nz n creireg ?!!!!!!? ... znlor arkg gvzr