> I'll speak to bc(1) and dc(1).   (In case you don't get to the end of this 
> e-mail, I don't think OpenBSD bc and dc are good replacements for GNU bc and 
> dc.)

Hi Phil.

Thanks a lot for your kindy and detailed email about my suggestion
for replacing bc(1) and dc(1).

> > It is not a 
> > licensing issue; in my humble opinion, there are good technical reasons
> 
> Good.  I like technical discussions.  

I like technical discussions too.

> Since I haven't investigated OpenBSD's bc(1) and dc(1) for a while, I thought
> I'd check them out again.  So I checked out the current versions from an 
> anoncvs site and got them running on NetBSD-2.0 (i386, 3.2Ghz machine).
> 
> Let me look at the points one by one:
> 
> a) better end-user documentation:
[...]
> Well, for the bc manual, the current (GNU) one has 799 lines versus 237 for 
> OpenBSD.  The GNU version is a much more comprehensive description of the 
> POSIX bc language with the GNU extensions.   All command line switches are 
> documented in full although they appear a little further down in the manual 
> than the OpenBSD version.  In fact, most current bug reports for GNU bc are 
> features documented in the manual page.
> 
> For the dc manual, the OpenBSD version has a few more lines than the GNU 
> version.  Again, all command line switches are documented.

I think that OpenBSD documentation for bc(1) and dc(1) is clear
and well organized.  It is more condensed that GNU's man pages
for those commands, some people will not like it, though.  But
IMHO it is mostly right.

> b) well written source code
> 
> This is a hard thing to quantify.  What specifically about the GNU version is
> not "well written source code"?
> 
> If you are talking about the methodology .... in that GNU bc is a complete 
> product not requiring GNU dc as a backend, that was a design decision.  I 
> wouldn't necessarily call one version superior to the other.  (OpenBSD bc 
> uses the original design of having bc being a preprocessor for dc.)

Code is clear and smaller.  It seems easier to maintain.  But the main
advantage is that, as you say, OpenBSD's/AT&T bc(1) is a preprocessor
for dc(1).  This design decision will make it easier to fix, as bugs
will not be repeated in different parts of the source code.  In other
words, a bug fix in bc(1) will improve dc(1) too.  It is the Unix
philosophy.  As observed some years ago by Bell Labs staff, each
command should do a simple task and do it well.  That is the key
for Unix being a successful operating system.

> c) better integration with the operating system source tree
> 
> I don't see how it is "better".   With OpenBSD bc, dc you have the following
> trees to compile bc and dc.
>   src/usr.bin/bc
>   src/usr.bin/dc
>   src/crypto/dist/openssl
>   src/lib/libcrypto  (reachover makefiles)
> 
> For GNU bc:
>    src/gnu/dist/bc
>    src/gnu/usr.bin/bc  (reachover makefiles)
>    src/gnu/usr.bin/dc  (reachover makefiles)

Indeed, but it has been developed for being integrated in the OpenBSD
source code, not as an external plug-in but as a part of the source
code itself.  On the other hand, OpenBSD is derived from NetBSD,
integrating these versions of bc(1) and dc(1) should be easy.

I did the same for diction(1) and style(1), just before discovering
that 2.11BSD has a different license that did not allowed that
software to be legally used.  :-(

> d) Although not mentioned in the original post, for me the real technical 
> issue is how does the product perform in use. The following are time tests on
> a variety of operations.  It is targetting the most expensive operations in 
> bc(1).   First, it checks out the math library and then looks at things like 
> multiplication, division, raising and square root.   As you will see, GNU bc 
> outperforms OpenBSD in many of the tests and some cases, OpenBSD can't even 
> do what GNU bc does.   In 2 cases below, I killed OpenBSD dc after it ran for
[...]
> 
> Timing exp.b with /usr/bin/bc
> 99836408603283573660347145562829683495827909199408566065153345558783\
> 9427595471.89114392327665123852
>         1.38 real         1.38 user         0.00 sys
> Timing exp.b with openbc
> time: Command terminated abnormally.
>       713.47 real       713.15 user         0.01 sys

Phil, I think that there is something wrong in this simulation:

$ uname -a
OpenBSD mail.forteisp.net 3.6 GENERIC#0 i386
$ time bc -l exp.b
998364086032835736603471455628296834958279091994085660651533455587839\
427595471.89114392327665123847
    7.36s real     7.27s user     0.02s system

Please, consider that the test machine is a relatively old computer (P3),
not a 3 GHz P4!

> Timing fact.b with /usr/bin/bc

(I do not have the source code for other tests... but it should
not be required.)

>         5.33 real         5.32 user         0.00 sys
> Timing fact.b with openbc
> dc: recursion too deep
>         0.13 real         0.11 user         0.01 sys

Indeed, it fails.  Perhaps it is a bug in this bc(1) or fact.b
is using a non standard extension.  I do not know.

> My conclusion is that OpenBSD bc and dc are not a good replacements for GNU 
> versions.   This is based on runtime performance.   We haven't even begun to 
> talk about POSIX compliance.   The above tests show that OpenBSD doesn't 
> comply with the POSIX output requirement that the \ in continuation numbers 
> is also to be counted in the line length.  So a line of a maximum of 70 
> characters, the default output line size, should have 69 digits and one \.   
> OpenBSD bc has 70 digits and the \.

This bug should not be difficult to fix.  Any operating system needs
improvements and following standards as strictly as possible is one
of the goals of all the *BSD operating systems.

I prefer tools that do not use non-standard extensions.  Sadly, GNU has
a lot of them (e.g., a lot of software packages are using extensions
provided by gmake that are not really required for building the binaries
but turn those packages on a nightmare to build on non-GNU environments).

In any case, the GNU versions of bc(1) and dc(1) can be available
in pkgsrc for those users that like it.

I feel better if I know that the scripts that I am writting in NetBSD
are portable to other operating systems because they are not using
proprietary extensions.

Best regards,
Igor.