[Toybox] Bc Math Library

[Gavin Howard]

Rob,

I will do string, though in a way dalias showed me that won't run up
against any C limitations.

However, I would still like to write scripts for merging myself. The
reason is that I would like to maintain my bc, even in toybox. That
way, if any bugs are found after release, I can put the fixes into my
bc and just merge again.

Gavin Howard

On Mon, Feb 19, 2018 at 12:17 PM, Rob Landley <rob at landley.net> wrote:
> On 02/16/2018 01:32 PM, Gavin Howard wrote:
>> Hello,
>>
>> The bc is coming along nicely. I am at the point where I may be ready
>> to support the POSIX-required "-l" option
>> (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/bc.html#tag_20_09_04).
>> That option requires a bunch of code written in bc itself to be
>> included with the program.
>
> In this case "a bunch" is maybe a kilobyte. Not a huge deal.
>
>> The code will be in its own file in the bc repo. However, it needs to
>> be converted into C source in some way because as Rob requested, the
>> library can only be contained as read-only data in the executable
>> itself to make sure there is no outside dependency.
>
> something like (untested):
>
> echo -n '#define BC_L "'
> sed 's/["\\]/\\&/h;s/$/\\n\\' bc_l.txt
> echo '"'
>
> I actually have a vague todo item to make string plumbing that allows a bunch of
> string text to be gzipped and then it would zcat them and grab the Xth
> null-termianted string. (I already need this for help text, and busybox has done
> something similar forever. It just needs lib/deflate.c to go in first...)
>
>> Here is my question: is the reduction in executable size and
>> (possible) faster startup time worth the complexity of the second
>> option?
>
> String. Definitely string.
>
> Just get it to work and get me code under the toybox license, I can handle
> merging it.
>
> Thanks,
>
> Rob