Re: [dev] [bc]

From: Evan Gates <evan.gates_AT_gmail.com>
Date: Thu, 15 Mar 2018 10:53:52 -0700

On Tue, Mar 13, 2018 at 1:56 PM, Michael Forney <mforney_AT_mforney.org> wrote:
> I know next to nothing about bc and what GNU extensions are used by
> timeconst.bc, but being able to build a linux kernel sounds like a
> good goal to me. However, if timeconst.bc can be changed to use only
> portable features of bc (in a way that is acceptable to upstream), I
> think that would be better than implementing the GNU extensions.

There is no way to write timeconst.bc with only POSIX bc and get
identical output without processing it in another script. POSIX bc
lacks the print and read keywords. To print a string you must include
the string on its own in double quotes. To print a value you must use
it as an expression. The problem is printing an expression is always
followed by a newline. As for read, it should be possible the change
the invocation to write "timeconst(number)" on stdin instead of just
the number, but again you need to change/add a layer above the bc
script.

The rest of the extensions are easy to avoid. Use single character
names, use braces for the body of the if on line 35 or move the body
up to the same line as the if, surround all return values with
parentheses, change halt to quit and put it on the last line.

That being said bc scripts with no extensions are extremely rare. The
extensions exist because they make the language usable. No one wants
to read a complicated script using single character variable names.
Try reading the bclib, it sucks. No one wants to switch between
languages in order to get input or print readable output. (Perhaps "no
one" is hyperbolic, but I sure as hell don't want to)

sbase is already full of extensions beyond POSIX. IMO it can use a few
more, notably the ability to handle nul bytes in files/streams instead
of being restricted to the POSIX definition of a text file. e.g. I
don't think sed should fail miserably when it encounters a nul byte
(it does now, and it's squarely my fault, I didn't take that into
account when writing it). The problem is getting people to agree to
the extensions and getting people to write the code.
Received on Thu Mar 15 2018 - 18:53:52 CET