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
