Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!mech.ubc.ca!latornell
From: latornell@mech.ubc.ca (Doug Latornell)
Newsgroups: comp.sys.atari.st
Subject: Floating Point Wierdness with Sozobon C
Message-ID: <301*latornell@mech.ubc.ca>
Date: 5 Mar 90 18:29:00 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 63


 
Consider the following piece of code: 

#include <stdio.h> 
#include <fplib.h>
main() 
{ 
  float  a; 
  FILE   *fopen(), *infile, *outfile; 
 
  infile = fopen("test2.dat", "rt"); 
  outfile = fopen("test2.out", "wt"); 
  fscanf(infile, "%f", &a); 
  fprintf(outfile, "a = %f\n", a); 
  fclose(infile); 
  fclose(outfile); 
  exit(0); 
} 
 
I use the command line "cc -vf test2.c" to compile this with 
Sozobon C version 1.1 and the libm.a library from fplib2.0.   
If test2.dat contains: 
0.01000000000 
(that's 9 0s after the 1) the result in test2.out is: 
a = 0.010000 
and everything is fine.  But, if I add a 0 to the contents of test2.dat: 
0.010000000000 
the result in test2.out is: 
a = 0.001410 
 
The value that stored in "a" seems to change with the value in test2.dat but I 
can't correlate the changes.  I'm pretty sure the problem is with fscanf() 
because this problem arise initially in a program that reads data from a file 
into a struct and uses v_pline() to display the data (after minor 
manipulation).  That program worked fine when compiled with Megamax C. 
 
Can anyone a) reproduce the results described above and b) suggest an  
explanation?   
 
Although I haven't tested this theory exhaustively, I think that fscanf() 
freaks out when the field it is reading contains more than 13 characters. 
Why this should be is beyond me.  I haven't yet delved into any of the  
compiler or library source code and am definitely *not* looking forward to 
doing so. 
 
BTW, my system configuration is: 
	1040STF (built in DS floppy) ca late 1986 
	TOS 1.0 in ROM 
	ST296N disk connected via ICD host adapter 
        using Gulam shell to drive Sozobon C
	AUTO folder contains: copyfix.prg   
                              icdtime.prg 
                              idle12.prg 
                              multivec.prg 
                              uis_ii.prg 
 
 
Doug Latornell        (latornell@mech.ubc.ca) 
CAM/Robotics Lab 
Mech. Eng. Dept. 
University of British Columbia 
Vancouver, British Columbia, Canada