On Thu, Dec 6, 2018 at 5:49 PM Gavin Howard <gavin.d.how...@gmail.com> wrote:
> To reduce the size significantly (Denys has reduced it some already,
> though in my mind, some of those changes are up in the air), you are
> going to have to make the bc not give good error messages and/or not
> check for errors as thoroughly (a massive chunk of the parser, which
> is the largest portion, is dedicated to error checking), reduce the
> quality of the code, reduce the performance of the math (though this
> would not remove much), or all of them combined.
>
> I think the best idea would be to accept my code (with changes), but
> just not enable it by default. Users can choose if they want it.
>
> Gavin Howard
> On Thu, Dec 6, 2018 at 6:37 AM Bernhard Reutner-Fischer
> <rep.dot....@gmail.com> wrote:
> >
> > Hi,
> >
> > Are you sure this is a good idea?
> > I was under the impression that it would be much more sane to write bc from
> > scratch given the extraordinary size of the proposed implementation.
Sure, ....any volunteers?
A few ideas how to cut this version of bc down further:
Remove limits checks - they are buggy anyway:
#define BC_MAX_SCALE ((unsigned) UINT_MAX)
#define BC_MAX_STRING ((unsigned) UINT_MAX - 1)
#define BC_MAX_NAME BC_MAX_STRING
#define BC_MAX_NUM BC_MAX_STRING
...
while ((c >= 'a' && c <= 'z') || isdigit(c) || c == '_') c = buf[++i];
if (i > BC_MAX_STRING)
return bc_error("name too long: must be [1, BC_NAME_MAX]");
On 32-bit machine, the above is dead code. On 64-bit machine...
*show me* a script with variable name >4 GB!!! No one does that!
Make POSIX warnings/errors configurable and disabled by default:
Just support all extensions when disabled.
Review size_t usage, change to unsigned where makes sense.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
