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

[enh]

On Fri, Jun 4, 2021 at 1:08 AM Rob Landley <rob at landley.net> 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210604/9b44d3fd/attachment-0001.htm>