On Fri, Jun 4, 2021 at 1:08 AM Rob Landley <[email protected]> wrote: > 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. >
i have to admit i was surprised that you'd left the enum. if i hadn't just had my second dose i might have thought a bit harder and waited. probably won't be a friday toybox update this week anyway :-) > (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... > i think -fwrapv is the option for "i'd rather have the language they _should_ have specified rather than the last 0.01% performance". as i've said many times, this is nothing to do with C++. it's all about the compiler writers promos being based on 0.01% benchmark improvements by exploiting loopholes in the language rather than closing the loopholes to make software safer. which is why -- as insecurity becomes ever harder to ignore -- we're starting to see some meaningful linguistic alternatives. to be fair, neither C nor C++ seems likely to be salvageable anyway, even if the compiler writers and folks on the standards committee were moving in the right direction. so maybe they're doing the world a favor by hastening their demise. (i haven't yet _used_ Rust, but i can't help but feel they managed to snatch defeat from the jaws of victory with signed integer overflow by having different behavior for debug and release builds --- aiui debug builds are the equivalent of -ftrapv and release builds the equivalent of -fwrapv. i've also never used Swift, but at least on paper that seems to actually be the best of the current options, explicitly forcing you to choose by using differently-spelled wrapping or trapping operators. Rust does have _all_ the choices: wrap, trap, saturate, or something very like C/C++'s __builtin_add_overflow, but [afaik] they're all as unergonomic as __builtin_add_overflow. Swift's `+` versus `&+` style -- though, again, i've never used it -- seems like something that would greatly improve a lot of the CVE-prone C/C++ i own. of course, Rust also has the command-line equivalents of -fwrapv and -ftrapv, but that means that "what + does" depends on context, which isn't the choice i would have made. i suspect this is leads to every file starting with the moral equivalent of Perl's `use strict` cruft.)
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
