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 <> 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
>> (
>> 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
Toybox mailing list

Reply via email to