[Maybe I should file this as a separate bugreport]

On Thu, 18 Dec 2003, Sven Luther wrote:

> tags 224417 + upstream
> thanks
> On Thu, Dec 18, 2003 at 09:15:40PM +0100, Thomas Fischbacher wrote:
> > 
> > Package:  ocaml 
> > Version: 3.06-21
> > Severity: grave
> 
> Huh ...
> 
> BTW, 3.06-21 is not part of debian anymore, but i guess 3.07-7 and the
> woody (and older) version are vulnerable.
> 
> I will transmit this to upstream too, altough i somewhat doubt they will
> fix it, since old-bignum is going to be replaced with the new
> implementation. But i think it will interest them still.

Yes, I suppose so. But strangely enough, the problem _did_ re-occur - 
albeit with very different values - with

Package: ocaml
Version: 3.07.2a-1

and

Package: libnums-ocaml
Version: 3.07-1

Here, I get:

0 ==> -63739694011402166976051874041676063865784980095311212432062478926751299450139305457948134038790907007782943115234375/2294287488095403763073974596800604256904498055825734116841519453845801891422853587965749144293625676308261780152348780234845939207145908383623706636688843241160704
1 ==> 0
2 ==> -12747938802280433395210374808335212773156996019062242486412495785350259890027861091589626807758181401556588623046875/11301908808351742675241254171431548063568955940028246880992706669191142322280066935791867705879929439942176256908122070122393789197763095485831067175807109562368
3 ==> 0
4 ==> -12747938802280433395210374808335212773156996019062242486412495785350259890027861091589626807758181401556588623046875/1280294357196095849929673324107480054076170790081324841987455052369309091195788832570172513556710756868449654102873203256052421432559100660504300578509399130112
5 ==> 0
6 ==> -12747938802280433395210374808335212773156996019062242486412495785350259890027861091589626807758181401556588623046875/11301908808351742675241254171431548063568955940028246880992706669191142322280066935791867705879929439942176256908122070122393789197763095485831067175807109562368
7 ==> -39148920061803210956691061036397438426365134774540146675772774556810648122275561412271743926625375084180283661376953125/2294287488095403763073974596800604256904498055825734116841519453845801891422853587965749144293625676308261780152348780234845939207145908383623706636688843241160704
8 ==> -570392894161458354485388740908288985192455282044195662517309148957502839351474204759670942202082333316731293944994384765625/95595312003975156794748941533358510704354085659405588201729977243575078809285566165239547678901069846177574173014532509785247466964412849317654443195368468381696
9 ==> -39148920061803210956691061036397438426365134774540146675772774556810648122275561412271743926625375084180283661376953125/2294287488095403763073974596800604256904498055825734116841519453845801891422853587965749144293625676308261780152348780234845939207145908383623706636688843241160704
- : unit = ()

Again, of course, zero is the correct value. At least, it does occur more 
frequently.


For sure, this made me wonder whether the bug may nevertheless be on my 
side, considering that I am terribly overworked due to this research paper 
at the moment, but I stared at the source over and over again, and I 
simply do not use global state / non-functional features outside of the 
main functions that could cause such behaviour... And even if I did, how 
could the results depend on the particular implementation of ratio 
arithmetics I am using? Yet to me it seems plausible that some serious 
issue may have been overlooked here, since I suppose very few people use 
ratio arith (in contrast to bignum-only arith, which has applications for, 
e.g., RSA).

This is all very puzzling at the moment...

-- 
regards,                  tf@cip.physik.uni-muenchen.de              (o_
Dr. Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)              V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                      (Debian GNU)