[Toybox] [PATCH] A "dc" implementation

[Rob Landley]

On 9/20/23 01:41, Oliver Webb via Toybox wrote:
> I have made a implementation of the 'dc' command in toybox
> 
> Since dc isn't specified in POSIX or LSB,

Which is why it's not in toybox?

There are things listed in yocto's root filesystem in the roadmap which I don't
intend to add to toybox. I'm unaware of any package build that uses dc, and as
far as I could tell it's redundant with shell $((math)) and expr and so on.

> I know that bc.c has a arbitrary precision library in it somewhere, 

I have a patch to remove the need for bc from the linux kernel build:

https://landley.net/bin/mkroot/0.8.9/linux-patches/0004-Replace-timeconst.bc-with-mktimeconst.c.patch

I haven't encountered anything else using it, but I haven't done the full
LFS/BLFS package builds yet so haven't confirmed that.

> But I haven't looked through the ~5700 lines of code
> for the command to see how they got it to work or how it could be shared with dc yet
> Everything that dc works with is just a long double as of now

Any package build in the past 25 years would have pulled in python or perl to do
arbitrary precision math if they actually needed it. (Which is almost never the
case, they generally just wanted 64 bit math.)

> Input and output radixes are much more trivial to get to work but much less important (Have less real use cases),
> I know that strtoll and friends have a input radix argument but I haven't looked into it that much yet.
> 
> As for strings macros and conditionals, I was originally planning to put these in because 
> it would turn what is essentially expr or $((shell math)) but more confusing, into a Turing complete language
> with branching, loops, recursion, etc. The main problem with that is that it turns the simple 2 functions you
> need to manipulate the stack in my implementation into at least 6 with separate error checking for every command
> because a value on the stack can either store a string or number so _every_ command needs to make sure it operates
> on the right one.
> 
> There are some bugs with it as well, mainly memory leaks I haven't diagnosed yet.
> They only leak the commands given to it so the cases where it's actually apparent we should be freeing memory
> is stuff like `yes p | dc` 
> 
> The other main bug I have found is that the part of the program 
> that gets statements to process _only_ breaks statements with whitespace
> so `2d+p` will not print 4 like it should and only adds 2 onto the stack.

Do you have an actual user for dc?

Rob