Strange Errors with Python-2.2.2

[Jeff Epler]

On Sun, Dec 22, 2002 at 01:32:32PM +0100, lemonite wrote:
> After searching through Python's source code, I recognized, that the
> funtion float_int() in floatobject.c is causing my trouble and its
> implementation has changed compared with Python-2.1.3. It seems, as if the
> call to modf() returns wrong results and to be sure I've tested modf()
> with the following C testfile:
> 
> #include <stdio.h>
> #include <math.h>
> 
> int main()
> {
> 	double x = 1.1;
> 	double y;
> 	
> 	printf("Calling modf() for %f\n", x);
> 	printf("fractional part = %f\ninteger part = %f\n",
> 					modf(x, &y), y);
> 	
> 	return 0;
> }

I think that the problems in the output are at least partially yours.  I
don't think that in the case of
	f( g(&a), a );
that f will be called with the value of a after the call to g completes.
In fact, my version of gcc (RedHat's infamous 2.96) calls with the old
value of 'a':

pushl   y+4		# push the two halves of the value of 'y'
pushl   y		# for the printf call
pushl   $y		# Push the address of 'y' for the modf call
pushl   x+4		# push the value of x
pushl   x		# for the modf call
call    modf		# call modf.  Result is in %st
addl    $4, %esp	# pop 4 bytes off the top of the stack
fstpl   (%esp)		# and now store the 8 bytes of the modf result 
			# over the locations which were previously used
			# as paramaters to modf
pushl   $.LC34		# push the format string
call    printf		# and finally, call printf.

I'd write the code snippet like this:
	x = modf(x, &y);
 	printf("fractional part = %f\ninteger part = %f\n",
 					x, y);
I don't know that it'll correct the output but I bet it'll at least make
the mingw output correct.

Jeff