[Toybox] [PATCH] md5sum: fix libcrypto build.

[Rob Landley]

On 6/3/21 4:16 PM, enh via Toybox wrote:
> OpenSSL uses the bare names like `MD5` itself.

Oops. Sorry.

> We could add a lot
> more #ifdefs instead, but it seems easier to just rename the toybox
> constants. I did check, and thanks to -ffunction-sections and
> -fdata-sections none of the built-in hash implementations end up in a
> libcrypto-using toybox, so it doesn't seem like there would be any other
> advantage to more #ifdefs.

I had some more cleanup I wanted to do anyway, which removes the enum.

(Glue enums like that violate SPOT. They can be a bit tricky to retroactively
remove from a design, and I myself am guilty of it in ps, but when possible I
try not to convert data representation TWICE. The info we need is already in the
name, and only main() and the hash setup function check it, so lookups can be
localized instead of having an intermediate data format living in TT that it's
converted to and then from again.)

I don't keep libssl-dev installed on my laptop so I can catch when the kernel
build tries to link against it, but I temporarily installed it and ran a build
against it and the new commit worked and passed "make tests".

Rob

P.S. I'm not sure the previous version would always have gotten the right sha384
and sha512 because if it wants 128 bits of count that can force it to advance
into the next frame. I.E. those need a MINIMUM padding of 8 bytes before a 64
bit count, which we weren't doing. I shuld come up with and add a test for that.
Anyway, if I'm going to add the bytes I might as well just track overflow, and
unsigned integer types are defined to wrap sanely no matter how much masochistic
C++ koolaid the gcc optimizer people drink...

P.P.S. Huh, I wonder if I can get gcc to stop "optimizing" out checkes for
signed integer overflow if I declare the darn variable volatile? No, I'm pretty
sure I would have tried that...