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... _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
