Ok, there was a need for OPENSSL_cleanse() instead of bzero() to prevent

supposedly smart compilers from optimizing memory cleanups away. Understood.

Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had
to be convoluted enough for the compiler not to recognize that this was
actually bzero() in disguise. Understood.

But then why there had been optimized assembler versions of OPENSSL_cleanse()
is beyond me. Did someone not trust the C obfuscation?

1 files changed, 0 insertions, 32 deletions

diff --git a/src/lib/libcrypto/ppccpuid.pl b/src/lib/libcrypto/ppccpuid.pl
index 4ba736a1d1..cf48714e33 100755
--- a/src/lib/libcrypto/ppccpuid.pl
+++ b/src/lib/libcrypto/ppccpuid.pl
@@ -93,38 +93,6 @@ Ladd:	lwarx	r5,0,r3
         blr
         .long   0
         .byte   0,12,0x14,0,0,0,0,0
-
-.globl  .OPENSSL_cleanse
-.align  4
-.OPENSSL_cleanse:
-        $CMPLI  r4,7
-        li      r0,0
-        bge     Lot
-        $CMPLI  r4,0
-        beqlr-
-Little: mtctr   r4
-        stb     r0,0(r3)
-        addi    r3,r3,1
-        bdnz    \$-8
-        blr
-Lot:    andi.   r5,r3,3
-        beq     Laligned
-        stb     r0,0(r3)
-        subi    r4,r4,1
-        addi    r3,r3,1
-        b       Lot
-Laligned:
-        $SHRLI  r5,r4,2
-        mtctr   r5
-        stw     r0,0(r3)
-        addi    r3,r3,4
-        bdnz    \$-8
-        andi.   r4,r4,3
-        bne     Little
-        blr
-        .long   0
-        .byte   0,12,0x14,0,0,0,2,0
-        .long   0
 ___
 
 $code =~ s/\`([^\`]*)\`/eval $1/gem;