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

[Rob Landley]

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpn.c
Type: text/x-csrc
Size: 4408 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240227/e865e43a/attachment.c>