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 <r...@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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
