it's perhaps worth mentioning in the "pros" column that toybox (a 0BSD-licensed busybox which provides most of /bin on Android, which i maintain) and busybox both use Gavin's bc/dc implementations[1]. so although the GNU versions are their own thing and i assume likely to stay that way, "all Android devices (plus any other toybox users) and everything that uses busybox" is a fairly significant chunk of the market if you're thinking about compatibility/interoperability issues.
____ 1. Android doesn't actually use the toybox copy of bc, it uses Gavin's upstream version directly. the only issue we've had with bc/dc on Android was from a bug that was introduced in toybox that was never in upstream. if you're thinking "how much use do bc/dc even get on Android devices anyway?", that's a fair point, but note that we also use host prebuilts of Gavin's bc/dc to _build_ Android (including all the third-party open source packages and the kernel, not just code we wrote). that was the _real_ reason for me to get into the business of shipping bc/dc! On Thu, Jun 17, 2021 at 9:08 AM Gavin Howard <[email protected]> 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). > > > 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 > >
