It wasn't a Utopia. Right from the start man pages reported BUGS, though many were infelicities, not implementation errors. Dennis once ran a demo of a ubiquitous bug: buffer overflow. He fed a 2000-character line on stdin to every program in /bin. Many crashed. Nobody was surprised; and nobody was moved to fix the offenders. The misdesign principle that "no real-life input looks like that" fell into disrepute, but the bad stuff lived on. Some years down the road a paper appeared (in CACM?) that repeated Dennis's exercise.

I’ve read that Ken wrote the kernel with an eye to it being a coding exemplar. Deliberately wrote consistent, high quality code.

On 8 Sep 2022, at 00:56, Larry McVoy <lm(a)mcvoy.com> wrote: I'd be willing to say that you could find a bug very quickly in our code but to claim that it is bug free is a bridge too far for me.

Would your folk ship code with a list of outstanding bug reports?

I don’t think Ken & Dennis did that.

On 9/7/22, Steve Jenkin <sjenkin(a)canb.auug.org.au> wrote: ** Everyone ** ships code with known bugs. If you insist on getting things perfect your code never gets out the door. At some point you have to decide that what you have is good enough to be released. The trick is to decide what constitutes "good enough". Some of it depends on your target application and user base. What's good enough for Hunt the Wumpus may well not be good enough for process control software for a pacemaker or nuclear reactor. And if you're producing software for commercial sale, marketing and business factors enter the mix as well. OTOH I'm certain that they did. -Paul W.

In addition, when Dennis would talk about Coherent and his evaluation of the source code, he said he used the known to him, but not widely known bugs in Unix to try to catch copying. If there was copying, those would be copied. If it was freshly implemented, there's a high likelihood that they wouldn't. His conclusion was that someone had access to a lot of knowledge about the Unix system given the fidelity of the implementation, but the lack of bugs and novel ways of doing it suggested independent implementation.

the source code, he said he used the known to him, but not widely known bugs in Unix to try to catch copying. If there was copying, those would be copied. If it was freshly implemented, there's a high likelihood that they wouldn't. His conclusion was that someone had access to a lot of knowledge about the Unix system given the fidelity of the implementation, but the lack of bugs and novel ways of doing it suggested independent implementation. Both Coherent and 4.4BSD have stuck out to me as examples of not-quite-so-clean-room implementations that did well enough (more than enough for BSD) and didn't die a fiery death in litigation (as much as USL tried...). What I find interesting is that in this day and age, it seems there is almost a requirement for true "clean-room" implementation if something is going to be replicated, which I understand to mean the team developing the new implementation can't be the same team that performed a detailed analysis of the product being reimplemented, but the latter team can produce a white paper/writeup/memorandum describing the results of their analysis and the development team can then use that so long as it doesn't contain any implementation details. I've always wondered how cleanly that sort of thing can actually be proven and enforced, and I've always thought back to the Coherent situation as an almost model example. Where proving copying outright can be difficult, knowing one's own product well enough to know the bugs that are incredibly obscure but also reliably consistent is a great way to peg a faithful recreation vs. a flat out copy job. That said, my assumption with complete UNIX re-implementations is that folks at least had access to the manuals, perhaps had used UNIX before in some capacity. I would assume the current definition of a clean-room implementation only requires that the developers/implementors don't have access to the code of the parent product (source or reverse engineered), but could read manuals, study behavior in-situ, and use that level of "reverse engineering" to extract the design from the implementation, so not knowing the gritty details, Coherent could be a true clean-room. BSD is a different beast, as they were literally replacing the AT&T source code before their eyes, so there isn't much argument that can be made for 4.4BSD being a "clean-room" implementation of UNIX. Simply for compatibility and upgrade-ability of existing systems, they had to be incredibly accurate to the original design. Given that, that's one of the more surprising things to me about 4.4BSD prevailing in the lawsuit, because while Berkeley could easily prove that they had replaced most of AT&T's code, there's still the fact that their team did have complete and unfettered access to Bell UNIX code at least circa 32V. Not sure if the licensing allowed for source-code cross-talk between USG/USL UNIX source and Berkeley, but I remember reading somewhere that CSRG students and faculty avoided commercial UNIX like the plague, going so far as to not even look at the literature to see what changes occurred since 32V. Anywho just some thoughts, I find the realm of reverse engineering and re-implementation fascinating, and am always interested in this sort of discussion. - Matt G. P.S. Don't want to derail the thread with this, unless it's deemed worthy addition, but feel free to email privately. Does anyone know if there was a "formal" PDP-11 and/or VAX disassembler produced by Bell? I know there was one floating around the "user maintained" utilities at some point, I recall seeing a note in a manual saying something to the effect "Rumor has it there is a PDP-11 disassembler" but I'm curious if such tools were ever provided in any sort of official capacity. I've been doing some research on what RE tools people had on hand at the time, think "objdump" from GNU binutils.