[Toybox] [PATCH] A "dc" implementation

[Oliver Webb]

------- Original Message -------
On Wednesday, September 20th, 2023 at 3:07 PM, Rob Landley <rob at landley.net> wrote:


> 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 was unaware of this, The other things that the stuff in the roadmap are from have been curated
to remove unwanted or out of scope commands from the roadmap so I thought the yocto project
would have been evaluated in a similar way before being put in the roadmap. 
Also, this command is mentioned in the roadmap in a context other then the yocto project. In the evaluation of the LFS packages
for which ones we would provide "complete-ish replacements for", both bc and dc are mentioned.

Which leads me into another question, what is your opinion about m4, make, yacc, and lex being in toybox?
In every evaluation of the POSIX commands in the talks I have watched and documentation I have read, those
commands are omitted on reason of being exclusively used to build packages, and therefore should be part
of the compiler tool-chain. I mostly agree with this, What confuses me is that these commands are some of
the fist items in a list of "Packages toybox plans to provide complete-ish replacements for" on the roadmap.
But when looking at the status page, none of the commands have been mentioned as things we actually want,
I am 99.999% sure these are commands we don't want to be in the project, but I thought it would be better to
ask anyways because those commands were put in that list for a reason.

> 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?

When I picked this command to write, I was going off the assumption that,
because it was the roadmap, Somebody cared enough about it to put it there.
And therefore would be the "user" who would benefit by it being implemented.

I could go on about how it has square roots when expr and shell $((math)) doesn't, 
or how the RPN stack layout of it _could_ be used to parse the numerical output
of commands easier when combined with external scripts. But those are justifications,
not actual use cases. I'd be lying if I said it wasn't mainly a "It's in the roadmap and busybox" thing.

> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net