[Toybox] [PATCH] bc.c: uchar typedef is pointless, we -funsigned-char

[Oliver Webb]

On Tuesday, February 27th, 2024 at 19:19, Rob Landley <rob at landley.net> wrote:
> On 2/27/24 13:46, Oliver Webb via Toybox wrote:
>
> > Since we build toybox with -funsigned-char, there is no reason to have a type for unnsigned chars in bc.c,
> > since that is the default for all chars. And removing it gets rid of a typedef
>
>
> Sigh, the bc in the tree is "fraught". The guy who submitted it said he was
> escaping from a cloud of drama at the time (I didn't care), and then was
> surrounded by a fresh cloud of drama after "escaping" and tried to suck me into
> it (I declined). He wandered off to busybox and also maintaining his command as
> a separate project.
>
> According to "wc toys//.c | sort -n" it is the largest command in the entire
> toybox tree. Larger than the shell despite not having a dozen subcommands nor
> needing to manage terminal control or child processes. It's 5 times the size or
> sed or tar, and at least 3 times the size it NEEDS to be. I'd far rather clean
> up xzcat or implement awk (each of which is a similar effort ballpark) than
> spend months cleaning it up.

Just a idea, but could we clean up the lexxer for bc, rip some of it out and make it it's
own separate thing (lib/lex.c?), then base awk off of that? I have barely looked through
the bc.c code and so far have only gotten the _really_ obvious things cleaned up. But since
there is a lexxer somewhere in there it is theoretically possible. I know the syntax differs in
a _lot_ of places, but they both share C style functions, control flow statements, logical operators,
etc. So they could share at least some common base?

When skimming through bc.c, I've found a lot of code for the -w (warn if GNU extension)
and -s (no GNU extensions) options. Since they only make sure the program does NOT provide
functionality, and enforce stupid things like single letter variable names (because bc was created
when someone in the 70s duct taped a lexxer to dc to give it C like syntax instead of rpn. and dc could
only store 255 variables as one character "registers")

I have never seen -w or -s used by anything, and mktimeconst.bc (the bc code in the linux-kernel)
uses plently of GNU extensions in it's code.

Would you mind if I stripped the logic of these options out of bc.c? Nothing USES them from my knowledge
and that would free up at least a few hundred lines of code (Probably more). And we would lose no
functionality from doing so as long as we keep the options there 

> Modern users who want to do funky math pull out python or something. Modern
> users who want to do non-funky math have $((math)) built into the shell, and
> expr, and are as likely to use dc as bc. A simple tool that does floating point
> math would be nice, and I got a submission of a tiny floating point calculator
> (attached) a couple years back which I haven't checked in yet because it's not a
> standard command and I don't know anybody under 50 who uses reverse polish
> notation, but I have a todo item to maybe have toysh's $[] syntax (a deprecated
> synonym for $(()) from before posix standardized that) do floating point math?
> (I mean, since it's deprecated...) Alas there's some design work: rpn.c uses
> letters for sqrt() sin() asin() cos() acos() tan() atan() and has a PI constant,
> where integer $((math)) in the shell expands any leftover strings it sees to
> shell environment variables. Still, pulling out function() calls before
> recognizing variable names isn't that big a lift... But let's get the base shell
> features all working first, then worry about extensions.
>
> But the FACT that people tend to do complex math in perl or $HOSTCC or similar
> means the only confirmed user of bc I've found is the linux kernel build, and
> I've had a patch to remove "bc" from that for ten years. (Which still worked
> last I checked, which was... the 6.7 release build I think?) I want to build
> linux from scratch, and then try to populate a debian repository under an LFS
> system (hard problem), and THEN decide whether to clean this command up or
> simply remove it. Maintaining "not bc" package builds is a heck of a lot less
> work than maintaining "builds against musl" package builds.
>
> There's no strong reason not to apply your patch, just...
>
> Rob

- Oliver Webb <aquahobbyist at proton.me>