<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 4, 2021 at 1:08 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/3/21 4:16 PM, enh via Toybox wrote:<br>
> OpenSSL uses the bare names like `MD5` itself.<br>
<br>
Oops. Sorry.<br>
<br>
> We could add a lot<br>
> more #ifdefs instead, but it seems easier to just rename the toybox<br>
> constants. I did check, and thanks to -ffunction-sections and<br>
> -fdata-sections none of the built-in hash implementations end up in a<br>
> libcrypto-using toybox, so it doesn't seem like there would be any other<br>
> advantage to more #ifdefs.<br>
<br>
I had some more cleanup I wanted to do anyway, which removes the enum.<br></blockquote><div><br></div><div>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 :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(Glue enums like that violate SPOT. They can be a bit tricky to retroactively<br>
remove from a design, and I myself am guilty of it in ps, but when possible I<br>
try not to convert data representation TWICE. The info we need is already in the<br>
name, and only main() and the hash setup function check it, so lookups can be<br>
localized instead of having an intermediate data format living in TT that it's<br>
converted to and then from again.)<br>
<br>
I don't keep libssl-dev installed on my laptop so I can catch when the kernel<br>
build tries to link against it, but I temporarily installed it and ran a build<br>
against it and the new commit worked and passed "make tests".<br>
<br>
Rob<br>
<br>
P.S. I'm not sure the previous version would always have gotten the right sha384<br>
and sha512 because if it wants 128 bits of count that can force it to advance<br>
into the next frame. I.E. those need a MINIMUM padding of 8 bytes before a 64<br>
bit count, which we weren't doing. I shuld come up with and add a test for that.<br>
Anyway, if I'm going to add the bytes I might as well just track overflow, and<br>
unsigned integer types are defined to wrap sanely no matter how much masochistic<br>
C++ koolaid the gcc optimizer people drink...<br>
<br>
P.P.S. Huh, I wonder if I can get gcc to stop "optimizing" out checkes for<br>
signed integer overflow if I declare the darn variable volatile? No, I'm pretty<br>
sure I would have tried that...<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>(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.)<br></div><div> </div></div></div>