Hello list.

Came across some weird behaviour when attempting a simple openssl ffi which I cannot reproduce in C alone.

Attached is the scheme code and the (more or less) equivalent C code.

The output of the scheme code is as follows: 81b637d8fcd2c6da6359e6963113a1170de795e4b725b84d1e0b4cfd9ec58ce9 81b637d8fcd2c6da6359e6963113a1170de795e4b725b84d1e0b4cfd9ec58ce9 8131333133333331333333333333333133333333333333333333333333333331 8131333133333331333333333333333133333333333333333333333333333331

The first line is the correct sha256 hash of the string "bob" from the sha256-final form. The second line is what should be (and is) the correct hash based on the byte array returned from sha256-final. The third line is the erroneous hash as a result of storing the hash string using sprintf using the same byte array as before. The final line is printing the resulting hash string from within scheme which should be the same as the third line (which it is and so is 'correctly' erroneous :).

The first problem/question is: why is sprintf screwing up? And why does it only screw up in bytes->string and not in sha256_final?

The second problem occurs when you swap the order of the two loops in bytes->string after which the output is: 81b637d8fcd2c6da6359e6963113a1170de795e4b725b84d1e0b4cfd9ec58ce9 3831333133333331333333333333333133333333333333333333333333333331 8131333133333331333333333333333133333333333333333333333333333331 8131333133333331333333333333333133333333333333333333333333333331

Why the hell is the second line now completely screwed up?

Interesting to note that the first hex value (81) is correct in the erroneous (sprintf) strings, yet after swapping the two loops around the first hex value (now 38) is different even though the rest of the erroneous hash string is the same.

Please release me from this madness.

PS: remember to pass "-lcrypto" when compiling.