> Okay, having actually did what Andy suggested, i.e. the one liner fix
> in the assembly code, bn_div_words returns the correct results.

Note that the final version, one committed to all relevant OpenSSL
branches since couple of days ago and one which actually made to just
released 0.9.8, is a bit different from originally suggested one-line
fix, see for example http://cvs.openssl.org/chngview?cn=14199.

> At this point, my conclusion is, up to openssl-0.9.8-beta6, the ppc32
> bn_div_words routine generated from crypto/bn/ppc.pl is still busted.

Yes. Though it should be noted that 0.9.8 was inadvertently avoiding the
bug condition. Recall that original problem report was for 0.9.7.

> Why do you signal an overflow condition when it appears functions that
> call bn_div_words do not check for overflow conditions?

That's question to IBM. By the time they submitted the code, I've
explicitly asked what would be appropriate way to generate *fatal*
condition at that point, i.e. one which would result in a core dump, and
it came out as division by 0 instruction. By that time I had no access
to any PPC machine and had to just go with it. Now it actually came as
surprise that division by 0 does not raise an exception, but silently
returns implementation-specific value... A.
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org