=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Igor,

On Saturday 26 March 2005 02:30, Igor Sobrado wrote:
> ...
> 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.

Well, this is more a style issue than a technical issue.   I'd personally=20
rather have the manual pages document the behavior of the command than
being short.   For obvious reasons, I'd prefer the current version

> Code is clear and smaller.  It seems easier to maintain.=20

I again disagree with you that smaller is necessarily better.    I also thi=
nk=20
that the GNU bc code is clear.   And in both cases, I suspect people who=20
are very familiar with the code will be the ones to maintain the code.

> But the main=20
> 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.=20

Sorry.  A bug fix in bc won't do anything for dc.   Yes, fixing a computati=
on=20
bug in dc will fix the same "bug in bc".     Similar things hold for GNU bc=
=20
and dc since they use the same code for the actual number routines.

> It is the Unix=20
> 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.

True, that was the philosophy.   But it has been a long time since it was
a prime philosophy.  =20

> > 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:

It is possible, but I used the OpenBSD bc and dc code from their anoncvs=20
server and I used the NetBSD copy of Openssl code for the big number=20
computations.  It is possible that a bug in Openssl has been fixed and sinc=
e=20
the release of of 2.0.  The executables are the exact thing I would get wit=
h=20
OpenBSD code running on a 2.0 system.   I don't have a -current machine up=
=20
and running to see if it has similar problems with the scripts.

> > 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.

Actually, all my tests are standard POSIX bc.   They were used to compare G=
NU=20
bc with the original AT&T bc as distributed for SUNOS.   This is a limitati=
on=20
of OpenBSD's dc.

> 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).

If you really do prefer tools that do not use non-standard extensions, than=
 in=20
that case your only choice is GNU bc.   GNU bc was carefully designed so it
could be run as a standard only processor.  The -s flag to GNU bc causes it
to accept ONLY POSIX standard features.   OpenBSD implements most of the
extensions originally done by GNU bc and does not have a way to disable=20
any of the extensions.   And on another note, GNU bc is easily made using
NetBSD's pmake.

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

The same could be said for the OpenBSD versions.

> 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.

Ok, here is a way to get the above now.   Add to your shell's login script
a line to define the environment variable  POSIXLY_CORRECT, and then=20
GNU bc will not let you use any extensions.   It will also make other tools=
=20
that watch for this environment variable and know how to process just POSIX
versions of the tools do just the POSIX versions.

Let me show you:
=2D ---->~
nooksack[2]$  POSIXLY_CORRECT=3D bc -v
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.

=2D ---->~
nooksack[3]$  POSIXLY_CORRECT=3D bc  =20
a=3D1;
for (;a<10;a++) a
(standard_in) 2: Missing expression in for statement
quit

=2D ---->~
nooksack[4]$  POSIXLY_CORRECT=3D openbc=20
a=3D1;
for (;a<10;a++) a
1
2
3
4
5
6
7
8
9

Enjoy POSIX bc!

Note, it is only more programming work to bring OpenBSD bc up to the place
where GNU bc is currently, but currently OpenBSD bc is not as good as GNU b=
c.

=2D --Phil =20

=2D --=20
Phil Nelson                       NetBSD: http://www.netbsd.org
e-mail: phil@cs.wwu.edu           Coda: http://www.coda.cs.cmu.edu
http://www.cs.wwu.edu/nelson=20
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCRk/+zbodwsP3RI0RAnY4AKCFCejPyruNWsYKOfo0HSr7no/BsgCfewFR
k25xUHXql+KL76h6qLwE6wY=3D
=3Dc5JN
=2D----END PGP SIGNATURE-----