[Toybox] Graff and bc

Rob Landley rob at landley.net
Wed Mar 14 19:43:34 PDT 2018


On 03/13/2018 03:24 PM, Gavin Howard wrote:
> I am about to try to implement your changes to bc_exec (and maybe
> bc_vm_init) in my release script. While doing so, if you would like,
> it would make sense to try to remove the BcStatus enum and replace it
> with either #defines (chars, so I can assign right to toys.retval) or
> something else of your choice. What would you like me to do?

Do we ever care about a bc command return status other than "nonzero"? Because
if so, you might as well just have error strings? Let's see...

grep -o 'BC_STATUS_[_A-Z]*' toys/*/bc.c | sort | uniq -c | sort -n

6 of them have an occurrence count of 1, which means they're never used (in the
enum, never referred to elsewhere.)

32 of them have an occurrence count of 2: used exactly once.

5 occur 3 times, 4 occur 4 times, 5 occur 5 times, and so on up. So several
occur repeatedly, and I'd have to look at why...

I'm still not sure the difference between LEX_EOF and PARSE_EOF, one is used 17
times and the other 11 but you're converting one into the other in some places
here...

Of course STATUS_SUCCESS is used 91 times. MALLOC_FAIL is 19 (see virtual vs
physical memory rant)...

tl;dr: I need more context and code review before forming a strong opinion about
the right thing to do here, and if I start I'll just start chipping away at
low-hanging fruit again. Waiting for you to come to a good stopping point first...

But I _suspect_ you can probably deal with the errors without having a lookup
table of signals between error producer and error consumer that's your own code
on both sides. That's the kind of thing that becomes clear once enough
overgrowth is cleaned up that the pieces get closer together.

Rob



More information about the Toybox mailing list