From: Michal Suchanek <hramrach@...>
Date: 2009-06-11T21:06:39+09:00
Subject: Re: [Security] Ruby 1.8.6-pl369 released

2009/6/11 Yukihiro Matsumoto <matz@ruby-lang.org>:
> Hi,
>
> In message "Re: [Security] Ruby 1.8.6-pl369 released"
>    on Thu, 11 Jun 2009 07:19:45 +0900, Michal Suchanek <hramrach@centrum.cz> writes:
>
> |> Could be, if we can define "reasonable range".
> |
> |Perhaps it could be set by a variable (like $KCODE).
>
> I, sort of, hesitate to introduce a new global state to the library.

The only way to work around this is by a global state of "reasonably
large exponent" which can be either fixed or configurable at runtime.

If that solution is accepted it should better be configurable.  It
could be even set to Inf by default for compatiblitity and people who
anticipate this could be a problem or were bitten by the issue already
can set it lower.

>
> |It might be useful to make it somewhat $SAFE dependent, too.
>
> Possible.
>
> |However, what is the issue here, exactly?
> |
> |Is it that a BigDecimal can have a large exponent for which zeroes
> |have to be generated while converting to a Bignum?
>
> Basically.  A huge BigDecimal could occupies large amount of memory,
> and consumes a lot of computational time.  It is fundamental, but
> bothering sometimes.
>

Then introducing an exponent to Bignum could probably resolve this
particular issue.

Truncating a Decimal should be easy and just shifting the exponent so
that no decimal digits remain should be reasonably fast as well.

This would, however, mean an incompatible change to Bignum because it
would have to track the number of zeroes which were left out. And
adding 1 to the resulting Bignum would still require the zeroes to be
generated.


Thanks

Michal