Path: utzoo!utgpu!watmath!iuvax!mailrus!cornell!ken
From: ken@gvax.cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Re: Bugs in interacting with the formatted output conversion functions ?
Message-ID: <34355@cornell.UUCP>
Date: 17 Nov 89 01:41:46 GMT
References: <1989Nov16.221608.29876@oxtrap.aa.ox.com>
Sender: nobody@cornell.UUCP
Reply-To: ken@gvax.cs.cornell.edu (Ken Birman)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 156

In article <1989Nov16.221608.29876@oxtrap.aa.ox.com> tc@oxtrap.aa.ox.com (Tse Chih Chao) writes:
>
>
>The following small program does not work under isis and it gives the
>following  output:
>
>sprintf float is: 0.000000
> printf float is 0.000000
>90.25 is : 0.000000
>90.25 in fprintf is: 0.000000
>
>It works ok without isis.  It seems to me that there is no separate
>xprintf functions defined in the isis libraries.
>
>------------------------cut here---------------------------------------
>#include <stdio.h>
>
>maintask()
>{
>    float  r;
>    char   str[50];
>
>
>    isis_start_done();
>    r=90.25;
>    
>    sprintf(str, "%f", r);
>    printf("sprintf float is: %s\n printf float is %f\n", str, r);
>    printf("90.25 is : %f\n", 90.25);
>    fprintf(stdout, "90.25 in fprintf is: %f\n", 90.25);
>
>    exit();
>}
>
>main()
>{
>    
>    isis_init(0);
>    isis_task(maintask, "main_task");
>
>    isis_mainloop(maintask);
>    exit(0);
>}
>Path: oxtrap!tc
>From: tc@oxtrap.ox.com (Tse Chih Chao)
>Message-ID: <TC.89Nov16170316@oxtrap.ox.com>
>Date: 16 Nov 89 17:03:16
>Organization: Ocwen Trading Inc. - Ann Arbor, MI
>Path: oxtrap!tc
>From: tc@oxtrap.ox.com (Tse Chih Chao)
>Message-ID: <TC.89Nov16165416@oxtrap.ox.com>
>Date: 16 Nov 89 16:54:16
>Organization: Ocwen Trading Inc. - Ann Arbor, MI
>Newsgroups: comp.sys.isis
>Subject: Bugs in interacting with the formatted output conversion functions ?
>Distribution: comp
>
>
>The following small program does not work under isis and it gives the
>following  output:
>
>sprintf float is: 0.000000
> printf float is 0.000000
>90.25 is : 0.000000
>90.25 in fprintf is: 0.000000
>
>It works ok without isis.  It seems to me that there is no separate
>xprintf functions defined in the isis libraries.
>
>------------------------cut here---------------------------------------
>#include <stdio.h>
>
>maintask()
>{
>    float  r;
>    char   str[50];
>
>
>    isis_start_done();
>    r=90.25;
>    
>    sprintf(str, "%f", r);
>    printf("sprintf float is: %s\n printf float is %f\n", str, r);
>    printf("90.25 is : %f\n", 90.25);
>    fprintf(stdout, "90.25 in fprintf is: %f\n", 90.25);
>
>    exit();
>}
>
>main()
>{
>    
>    isis_init(0);
>    isis_task(maintask, "main_task");
>
>    isis_mainloop(maintask);
>    exit(0);
>}
>Newsgroups: comp.sys.isis
>Subject: Bugs in interacting with the formatted output conversion functions ?
>Expires: 
>References: 
>Sender: 
>Reply-To: tc@oxtrap.UUCP (Tse Chih Chao)
>Followup-To: 
>Distribution: 
>Organization: Ocwen Trading, Inc.
>Keywords: 
>
>
>
>The following small program does not work under isis and it gives the
>following  output:
>
>sprintf float is: 0.000000
> printf float is 0.000000
>90.25 is : 0.000000
>90.25 in fprintf is: 0.000000
>
>.... (program followed)

I ran this program on an ISIS system under SUN OS 4.0.3 (a SUN 3/60)
and it gave the correct output.

Some possibilities to explore:

1) ISIS defines a routine called "print"; it does a printf and then
   an fflush(stdout); we use it to get diagnostic output from programs
   that might crash before flushing.

   Could you please compile this program WITHOUT the ISIS libraries
   and check to see if "_print" is defined:
	a) edit to remove calls to isis.	
	b) cc with normal libraries
	c) nm a.out | grep _print

   If so, you are seeing an interation between the ISIS version of
   print and some (non-standard) version in use on your machine.

2) Was this the EXACT code you compiled?  Probably not, since it lacks
   the isis.h include...

3) Are you on a non-standard UNIX system, e.g. one with floating point
   emulation or some other strange feature?  If so, perhaps ISIS interacts
   with that in some way?

4) If all else fails, how about running "cc -S" and looking at the assembler
   output.  If this looks ok, run adb on a core image (generate one with
   *(int*)1 = 99) and see if the instruction sequence should have worked.  Or,
   run dbx and verify that the args to printf are valid ones...

Basically, what I am getting at is that I don't think this is our fault.
If you can give me enough data to reproduce the problem I will post a
fix.

Ken