[Toybox] awk seen in the wild

[enh]

On Fri, Jul 15, 2016 at 2:54 AM, Rob Landley <rob at landley.net> wrote:
>
>
>
> On 07/14/2016 04:43 PM, enh wrote:
> > On Thu, Jul 14, 2016 at 2:35 PM, Rob Landley <rob at landley.net> wrote:
> >>
> >> On 07/13/2016 05:38 PM, enh wrote:
> >>> looks like i never sent my previous patch to the list, and looks like i
> >>> lost it on disk too. (it's probably still *somewhere*, but at some point
> >>> it's cheaper to stop looking and just do it again...)
> >>>
> >>> attached is a rewrite that shows the basic idea, but misses the step of
> >>> refactoring your portable implementation to look like the libcrypto one
> >>> so we can remove the 10 lines of duplication. (the majority of the lines
> >>> added to this patch is just the same help text duplicated over and over.)
> >>>
> >>> this actually makes toybox faster than the version in ubuntu 14.04.
> >>
> >> Grumble grumble.
> >>
> >> Sigh.
> >>
> >> Fidget.
> >>
> >> Grrr...
> >>
> >> [Sleeps on it; next afternoon...]
> >>
> >> This is almost certainly the right thing to do. Lemme figure out where
> >> the new edges of this can of worms are.
> >>
> >> I know that no external library should ever be REQUIRED by the build.
> >> And I still want the hermetic/selfhosting builds to work with defconfig
> >> toybox, so may wind up adding builtin slow/simple implementations of
> >> more stuff that libraries provide optimized versions of.
> >
> > yeah, that's actually a very good argument for the portable
> > implementations that hadn't occurred to me.
> >
> >> But yes, I should apply this. Lemme finish up my pending md5sum changes
> >> first though. (I'm 2/3 of the way through adding -c support.)
> >
> > no hurry. like i said, i've had a patch like this hanging around for
> > so long that i literally couldn't find it any more :-) at least
> > there's something in the list archives now!
>
> One rough edge is that if you build a statically linked standalone sha1
> app, it'll suck in the hash functions for all of these:
>
>     HASH_INIT("md5sum", MD5), HASH_INIT("sha1sum", SHA1),
>     HASH_INIT("sha224sum", SHA224), HASH_INIT("sha256sum", SHA256),
>     HASH_INIT("sha384sum", SHA384), HASH_INIT("sha512sum", SHA512),
>
> I dunno if they share plumbing internally (probably not if they're
> optimized), but the compiler can't tell that this table entry's string
> won't be matched this build.
>
> If I'd kept the individual functions and initialized the structure
> there, then maybe it could tell...
>
> Anyway, I wrapped the relevant USE_ macro around each one.
>
> (I'm amused that even doing that, the dynamically linked -libcrypto is
> slightly _larger_ than the one with the built-in hash function.)

for the single toy, not because of the duplicated help text? that seems odd.

> (The segfault that took a while to track down is because SHA512_CTX and
> friends are bigger than SHA_CTX so it was stomping the stack when I
> tested those. Fixed now, and seems to be working...)

sorry... i remember i made that mistake last time too, assuming that
SHA meant "generic" not "SHA1 but for some reason we only included the
numbers on all the other variants". even if it was a historical
accident, i wish they'd gone back and typedef/#define'd over the mess.

> Rob




-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.