Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
On Fri, Jul 30, 2021 at 09:54:27AM -0600, Gavin Howard wrote: > Whoops; I thought Theo would make the decision, and his last email made > me think he might have. > > I am happy to help as much as I can to make the process easy for you. > > In the meantime, I think I will release 5.0.0 when it's ready. I'll take > into account your feedback in a future release. > > Gavin Howard > It's mostly a question of finding time. As for the decision to import itself, Theo listed important drawbacks of importing something from upstream into our base. The advantages of doing that must be very big to outweight the disadvantages. Given that current dc and bc are quite ok (if I may so myself), the chances of your code getting into base are quite slim indeed. -Otto
Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
Whoops; I thought Theo would make the decision, and his last email made me think he might have. I am happy to help as much as I can to make the process easy for you. In the meantime, I think I will release 5.0.0 when it's ready. I'll take into account your feedback in a future release. Gavin Howard
Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
On Thu, Jul 29, 2021 at 10:31:34PM -0600, Gavin Howard wrote: > Hello, > > At this point, because of the lack of reply, I am going to assume that > my proposal is rejected. While I am sad, I understand. > > Thank you for taking the time to consider my proposal. > > Gavin Howard > I just did not find the time to look at it. Sorry for that. I still might one day. -Otto
Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
Hello, At this point, because of the lack of reply, I am going to assume that my proposal is rejected. While I am sad, I understand. Thank you for taking the time to consider my proposal. Gavin Howard
Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
On Thu, Jun 17, 2021 at 9:48 AM Otto Moerbeek 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 > > > >
Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
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 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 > >
Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
Mr. de Raadt, > Eyes will usually look at the version they are used to, and any effort > to shink the number of versions will probably fail to re-adapt those > eyes towards looking at another version with the same focus, as they are > not familiar with the replacement. I think you are correct here. However, having more *users* does imply that bugs would be run into more often. When users report bugs, I fix them. (See [1] [2] [3], and there are many more by email.) This means that even if there are no more eyes than mine looking at the code, more bugs will be fixed. Also, I have spent a lot of time making these programs as high quality as I can. When I said that they have been fuzzed thoroughly, I wasn't kidding. For this upcoming release, I have already fuzzed them and found no crashes or memory bugs, and I will still fuzz them again after I take into account all of your feedback. > Additionally, all software efforts also face a limit on the number of > cooks huddled in the kitchen, so I do not believe the development > community grows in that way. I don't know of any succesfull examples > where divergent teams merged into a single track. The fact that divergent teams do not merge also implies that divergent programs may not become more consistent with each other either. > To me, it seems best if we urge everyone to craft their independent > implementations towards consistency, and conversation on those details > is important to get there. I am not sure consistency will happen here, especially with dc(1), but even with bc(1). For example, the incompatibility with the `length()` function is an ambiguity that is fundamental to math because the POSIX standard defers to the mathematical definition of "significant digits." The POSIX standard is also ambiguous on whether numbers with all zeros after the decimal point count as integers, which is important because the power `^` operator requires an integer argument on the right. For my implementations, I tried to follow the standard as best I could, but these ambiguities pop up over and over. But dc(1) is even worse because there is no standard; there are only implementations from years ago. I based my dc's behavior on the OpenBSD manpage specifically, but there were important things that were not documented. In my opinion, one of the advantages of my bc and dc is that I have tried very hard to document and guarantee every bit of behavior. I am even working on a document about how to do development on them. [4] > There is another problem in our tree: The use of external upstream > managed code is a royal pain in the ass. We do it where we have to, > but the process for managing that kind stuff is a culturally weird. I can't disagree, but what I can say is that I am willing to make this a non-issue by making my code build using OpenBSD's infrastructure, especially OpenBSD's `make`, so that you will not notice a difference. That would include adapting my test suite to work in `regress/`, as well as adapting existing dc and bc scripts in the tree, among other things. And then I would take responsibility for maintaining those adaptations. If I do, then if these are accepted, Otto doesn't have to worry about bc(1) and dc(1) anymore; that would be my job. However, you said before that there might be too many cooks in the kitchen, so only you can decide if that would work for OpenBSD. I can understand if it would not. Gavin Howard [1]: https://github.com/gavinhoward/bc/issues/31 [2]: https://github.com/gavinhoward/bc/issues/3 [3]: https://git.yzena.com/gavin/bc/issues/4 [4]: https://git.yzena.com/gavin/bc/src/branch/master/manuals/development.md
Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
enh wrote: > 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 :-( ) Eyes will usually look at the version they are used to, and any effort to shink the number of versions will probably fail to re-adapt those eyes towards looking at another version with the same focus, as they are not familiar with the replacement. Additionally, all software efforts also face a limit on the number of cooks huddled in the kitchen, so I do not believe the development community grows in that way. I don't know of any succesfull examples where divergent teams merged into a single track. To me, it seems best if we urge everyone to craft their independent implementations towards consistency, and conversation on those details is important to get there. There is another problem in our tree: The use of external upstream managed code is a royal pain in the ass. We do it where we have to, but the process for managing that kind stuff is a culturally weird.
Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
Having fewer versions of software is not neccessarily a plus. It is easily considered a negative. enh wrote: > 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 > 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 > > > >
Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
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: $ 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 >
Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
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
Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)
On Wed, Jun 16, 2021 at 11:40:08PM -0600, Gavin Howard wrote: > Hello, > > My name is Gavin Howard. I have developed a new bc(1) and dc(1) > implementation. [0] > > I propose replacing the current implementations with mine. > > Advantages: > > * Performance. [1] > * Extensions for ease of use. > * With build options to remove most extensions, if desired. > * Compatible with GNU bc. > * Already used by default in FreeBSD. > * Fuzzed thoroughly. > * No exec needed for bc(1) (both programs are contained in the same > multi-call binary). > > Expectations met: > > * Already uses pledge(2) and unveil(2). > * No dependencies beyond C99, POSIX `make`, and POSIX `sh`. > * This includes no dependency on editline(3), even though my bc(1) > and dc(1) have a history implementation. > * Thorough test suite. > * Comprehensive man pages. > * Locale support. > > Disadvantages: > > * There are incompatibilities with the current bc(1) and dc(1), which > are listed below. All users would need to be made aware of these > incompatibilities, so they can update scripts, and scripts in `src/` > will also need to be updated. > > Incompatibilities (failing tests from `regress/usr.bin`): > > 1. Current bc(1) and dc(1) return 0 for length(a) where a is 0. Mine >return 1. This causes my dc(1) to fail `dc/t1.in` and `dc/t28.in`. > 2. Current dc(1) implements arrays as part of registers. Mine keeps >arrays and registers separate. This causes my dc(1) to fail >`dc/t1.in` and `dc/t8.in`. > 3. Current dc(1) does not print a `nul` byte if given the `P` or `a` >commands with 0 on the top of the stack. My dc(1) does (because it >considers 0 to have one digit, see #1). This causes my dc(1) to fail >`dc/t3.in` and `dc/t13.in`. > 4. Current dc(1) starts with empty registers, and allows the user to pop >all items off the register stack. My dc(1) starts with a single item >in the register and does not allow the user to remove it. > 5. Current dc(1) will push an item onto a register stack for the `s` >command. My dc(1) does not since one already exists. This, combined >with #4, causes my dc(1) to fail `dc/t5.in` > 6. Current bc(1) and dc(1) have a larger maximum `obase` than mine. This >causes my dc(1) to fail `dc/t9.in`. > 7. Current dc(1) does not reset on errors. My dc(1) does, so it fails >`dc/t12.in`. > 8. Current dc(1) allows register names with any character. My dc(1) >requires non-control characters and has a different way of doing >extended registers. This causes my dc(1) to fail `dc/t15.in`, >`dc/t16.in`, `dc/t19.in`, `dc/t21.in`, and `dc/t23.in`. > 9. Current bc(1) is a frontend to dc(1). Mine are combined into the same >binary and generate and run bytecode. This means that my bc(1) fails >all of the bc(1) regression tests (which generate dc(1) code) and >does not have the `-c` option. > > Notes: > > My dc(1) also fails `dc/t10.in` because it doesn't have the `!` command, > but https://github.com/openbsd/src/commit/dc405aa075 makes it appear as > though the current dc(1) does not have the `!` command either. > > In https://youtu.be/gvmGfpMgny4?t=1277 , Bob Beck said that unveil(2) > must not be used on command-line arguments, so I use unveil(2) after all > command-line files are executed. > > Current version is 4.0.2. I am planning to release version 4.1.0 soon, > but held off in case you are interested and had feedback that might > help. > > I am willing to help maintain them if they are put into OpenBSD, but I > am also willing to pass them off to whoever you wish, should you wish to > do so. > > I do have a mirror on GitHub. > > If you are not interested, feel free to ignore this email. > > Regardless, thank you for your time. > > Gavin Howard > > [0]: https://git.yzena.com/gavin/bc > [1]: https://git.yzena.com/gavin/bc/src/branch/master/manuals/benchmarks.md > 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. 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. I'll take a look at your code soon and maybe other devs have opinions. -Otto
[CAN IGNORE] Proposal for new bc(1) and dc(1)
Hello, My name is Gavin Howard. I have developed a new bc(1) and dc(1) implementation. [0] I propose replacing the current implementations with mine. Advantages: * Performance. [1] * Extensions for ease of use. * With build options to remove most extensions, if desired. * Compatible with GNU bc. * Already used by default in FreeBSD. * Fuzzed thoroughly. * No exec needed for bc(1) (both programs are contained in the same multi-call binary). Expectations met: * Already uses pledge(2) and unveil(2). * No dependencies beyond C99, POSIX `make`, and POSIX `sh`. * This includes no dependency on editline(3), even though my bc(1) and dc(1) have a history implementation. * Thorough test suite. * Comprehensive man pages. * Locale support. Disadvantages: * There are incompatibilities with the current bc(1) and dc(1), which are listed below. All users would need to be made aware of these incompatibilities, so they can update scripts, and scripts in `src/` will also need to be updated. Incompatibilities (failing tests from `regress/usr.bin`): 1. Current bc(1) and dc(1) return 0 for length(a) where a is 0. Mine return 1. This causes my dc(1) to fail `dc/t1.in` and `dc/t28.in`. 2. Current dc(1) implements arrays as part of registers. Mine keeps arrays and registers separate. This causes my dc(1) to fail `dc/t1.in` and `dc/t8.in`. 3. Current dc(1) does not print a `nul` byte if given the `P` or `a` commands with 0 on the top of the stack. My dc(1) does (because it considers 0 to have one digit, see #1). This causes my dc(1) to fail `dc/t3.in` and `dc/t13.in`. 4. Current dc(1) starts with empty registers, and allows the user to pop all items off the register stack. My dc(1) starts with a single item in the register and does not allow the user to remove it. 5. Current dc(1) will push an item onto a register stack for the `s` command. My dc(1) does not since one already exists. This, combined with #4, causes my dc(1) to fail `dc/t5.in` 6. Current bc(1) and dc(1) have a larger maximum `obase` than mine. This causes my dc(1) to fail `dc/t9.in`. 7. Current dc(1) does not reset on errors. My dc(1) does, so it fails `dc/t12.in`. 8. Current dc(1) allows register names with any character. My dc(1) requires non-control characters and has a different way of doing extended registers. This causes my dc(1) to fail `dc/t15.in`, `dc/t16.in`, `dc/t19.in`, `dc/t21.in`, and `dc/t23.in`. 9. Current bc(1) is a frontend to dc(1). Mine are combined into the same binary and generate and run bytecode. This means that my bc(1) fails all of the bc(1) regression tests (which generate dc(1) code) and does not have the `-c` option. Notes: My dc(1) also fails `dc/t10.in` because it doesn't have the `!` command, but https://github.com/openbsd/src/commit/dc405aa075 makes it appear as though the current dc(1) does not have the `!` command either. In https://youtu.be/gvmGfpMgny4?t=1277 , Bob Beck said that unveil(2) must not be used on command-line arguments, so I use unveil(2) after all command-line files are executed. Current version is 4.0.2. I am planning to release version 4.1.0 soon, but held off in case you are interested and had feedback that might help. I am willing to help maintain them if they are put into OpenBSD, but I am also willing to pass them off to whoever you wish, should you wish to do so. I do have a mirror on GitHub. If you are not interested, feel free to ignore this email. Regardless, thank you for your time. Gavin Howard [0]: https://git.yzena.com/gavin/bc [1]: https://git.yzena.com/gavin/bc/src/branch/master/manuals/benchmarks.md
