[Patches] fix overflow bug in ldexp(x, exp)

[Trent Mick]

On Mon, May 08, 2000 at 10:35:19AM -0400, Guido van Rossum wrote:
> Thanks, Trent.  I've applied this patch, but actually I'm a little
> confused.
> 
> On Solaris 2.7, I'm now getting this:
> 
>   >>> ldexp(1, 100000000)
>   Traceback (most recent call last):
>     File "<stdin>", line 1, in ?
>   OverflowError: math range error
>   >>> ldexp(1, sys.maxint-1)
>   Traceback (most recent call last):
>     File "<stdin>", line 1, in ?
>   OverflowError: math range error
>   >>> ldexp(1, sys.maxint)			# this takes a second or two...
>   Infinity					# ...expected OverflowError!
>   >>>
> 
> I have a feeling though that this is a bug in the C math library --
> not sure if it's worth fixing.  On Linux I get an OverflowError as
> expected for sys.maxint.

It seems to me, as well, that that is a C math library bug. It is not
returning an ERANGE errno. Can you reproduce this with a simple C program, on
Solaris?

#include <stdio.h>
#include <math.h>
#include <errno.h>
#include <linits.h>
int main(void)
{
	double x;
	printf("ldexp(1.0, %d)=%lf\n", INT_MAX, ldexp(1.0, INT_MAX));
	printf("errno = %d (ERANGE=%d)\n", errno, ERANGE);
}


> 
> Note that ldexp(1, 3.14) is still accepted!  The 'i' format calls
> tp_int for floats and int(3.14) is 3.

That is another matter. I don't know what I should expect the 'i' formatter
to do. It calls PyInt_AsLong. Should PyInt_AsLong complain if it is given a
PyFloatObject? That is a philosophical question that is kind of moot here
(its behaviour is not going to change).

I think that ldexp() should *not* accept a float for the 'exp' argument
because the rounding to an int is not obvious to the user. I suppose the 'O&'
formatter could be used with a special converter that raises a TypeError if
the argument is not an integral type (i.e. PyInt or PyLong). Is it worth
making that change? Is it even desired to make that change because it might
break some code out there.

thanks,
Trent

-- 
Trent Mick
trentm@activestate.com