On Thu, Jun 17, 2021 at 9:48 AM Otto Moerbeek <o...@drijf.net> wrote:

> On Thu, Jun 17, 2021 at 10:01:02AM -0600, Gavin Howard wrote:
>
> > Otto,
> >
> > > I think it is interesting. As for the incompatibilites, my memory says
> > > I followed the original dc and bc when deciding on those (GNU chose to
> > > differs in these cases). Bit it has been 18 years since I wrote the
> > > current versions, so I might misrememeber.
> >
> > I think that makes sense to me. Unfortunately, when I was building my
> > dc, I couldn't find any mention in the OpenBSD man pages, which I used
> > to ensure as much compatibility as I could, that arrays and registers
> > were not separate. Well, there was one (the `;` command mentions
> > registers, but the `:` command does not, so I thought that was a typo).
> >
> > Regarding the 0 having length 0 or 1, that was a decision I agonized
> > over. My dad, who is a mathematician, said that it could go either way.
> > Unfortunately for me, if this is a showstopper incompatibility (and it
> > might be based on how the test suite uses `length()` and `Z`), I do
> > think I would keep it as it is and accept that OpenBSD will not want my
> > bc(1) and dc(1).
>
> It looks like GNU dc and bc do not agree:
>

heh. while i know what Theo means -- and his is also a valid philosophical
standpoint -- this kind of thing is one reason why i personally prefer
fewer implementations of things and more shared code between them :-)

at least it leads to more consistency, and to having fewer places to fix.
(since i think we've all had enough counterexamples to not believe that
whole "many eyes" thing, the real question is "how easily/quickly can you
make fixes, and how easily/quickly can you distribute them?"... given how
few eyes are actually open, i'd rather have them all looking at the same
set of problems :-( )


> $ dc -V
> dc (GNU bc 1.06) 1.3
>
> Copyright 1994, 1997, 1998, 2000 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There
> is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE,
> to the extent permitted by law.
> iMac:~ otto$ dc
> 0Zp
> 0
>
> and
>
> $ bc
> bc 1.06
> Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
> This is free software with ABSOLUTELY NO WARRANTY.
> For details type `warranty'.
> length(0)
> 1
>
> I confirmed the original dc by Morris and Cherry indeed print 0 for
> the above test case.
>
>         -Otto
> >
> > > As for moving to your version, I have no opinion yet. I have some
> > > attachment to the current code, but not so strong that I am opposing
> > > replacement upfront. OTOH the current implementaion is almost
> > > maintainance free for many years already. So I dunno.
> >
> > You have a right to have attachment to it; I have attachment to mine!
> >
> > In fact, I was pleasantly surprised at how clean and readable your code
> > was. I usually struggle to read code written by others, but I could
> > easily read yours.
> >
> > On that note, since last night, I thought of more disadvantages of
> > moving to my bc and dc, which I feel I must mention.
> >
> > More disadvantages:
> >
> > * The current dc(1) and bc(1) are from a known member of the OpenBSD
> >   community with many contributions. I am an unknown quantity.
> > * The current dc(1) and bc(1) do not have ugly portability code that
> >   OpenBSD probably doesn't care about.
> > * The current dc(1) and bc(1) do not have ugly code to support build
> >   options that OpenBSD does not care about.
> > * The binary size of the OpenBSD dc(1) and bc(1) combined are 78% the
> >   size of mine combined (on amd64). The size of OpenBSD combined is
> >   145440, and the size of mine combined are 185706.
> > * The current dc(1) and bc(1) have much less source code and have been
> >   nearly maintenance-free for many years. Mine were started in 2018 and
> >   do not have as long of a track record for being low maintenance.
> >
> > > I'll take a look at your code soon and maybe other devs have opinions.
> >
> > Thank you very much!
> >
> > Gavin Howard
> >
>
>

Reply via email to