What's fascinating is that I recently found some code that I believe was written in NB [1]. It's compiled to threaded code (like B) but knows about chars (like C). It doesn't quite match the story, but I don't know what else it could be
I like the curiosity of the Amiga OS that was developed in an interim period between BCPL and its successor C. Amiga OS was originally based on a port of TRIPOS to the Motorola 68000 by MetacomCo. It was eventually replaced but it would take some time. In AmigaOS 1.x, AmigaDOS is still based on TRIPOS and thus written in BCPL. BCPL didn't have native pointers so applications were difficult to write and error-prone. AmigaOS 2.x rewrote it in C but maintaining compatibility to BCPL where possible so IIRC it was somewhat littered with shims for that. Only in AmigaOS 4 was the BCPL heritage completely shed, 20 years later!
Nowadays, AmigaDOS sounds like a true antiquity but at the time, I remember I always found the shell surprisingly capable and modern! Especially for what was first and foremost a home entertainment system (although Commodore didn't want it to be only that). We even mounted volumes under arbitrary names, much like on Unix, had RAM drives and even RAD drives -- semi-persistent drives that made use of the fact that its RAM circuits were persistent enough to survive reboots!
I absolutely felt like I was thrown back in time when finally going PC and I suddenly no longer had my DOS able to multitask in a visual environment with all these features, and rather had to challenge myself with freeing up 600 KB of conventional RAM...
Amiga cane decades after C. It was only due to a geographic quirk that people were still using BCPL at that time. They could have used C (for years) but chose not to.
It took me until around 1998 before it felt "right" for me to finally switch from my beloved Amiga 3000 to PCs running either Win95 or NT4, and even then some specific use cases (like trying to work on the command line) felt entirely medieval compared to the Amiga. At least the games were better on PC though.
More accurately, the earliest "C Reference Manual" that I have seen has the date 1974-01-15.
It includes all the new features that have differentiated C from B, most of which have been implemented during the summer of 1973. Therefore, by January 1974 C was complete.
The next significant modifications of the language after that date have occurred only during the ANSI standardization process (which ended in 1989, so perhaps the poster above has meant that Amiga happened between K&R C and ANSI C).
I first learned C on an Amiga, back in 1989 or so (Lattice C compiler, which became SAS/C.) All the books and documentation at the time was K&R style. Around 1991 or so, I remember reading K&R second edition, which was ANSI C.
TRIPOS was developed in 1976-1979, with the 68000 port finished in 1981.
Only the Amiga's disk operating system and command-line shell were from TRIPOS. The underlying "Exec" (microkernel) had been developed at Commodore-Amiga: It was close enough to similar facilities in TRIPOS that it made porting relatively simple.
Commodore-Amiga had originally hired another company to write the DOS, called "CAOS" (Commodore Amiga Operating System), originally intended to have been even more similar to Unix than TRIPOS was. But that company had failed to deliver, and the release date was fast approaching, so the choice of TRIPOS was an emergency solution.
Yeah I really wish the copyright holders would give it up and open source OS4. It’s one the few sweet spot personal OS’s that are single user multi tasking. I guess AROS is close but it’s clunky.
"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions."
Nowadays it silences -Wunused-perameter. I'm not a fan as it just adds nonfunctional clutter only needed to appease a tool. The tools are supposed to work on our behalf, not against.
We can also silence -Wunused-perameter by omitting the parameter name in the prototype. No clutter, I'm personally fairly happy with this solution. (Note: the declaration in the header can sill name the parameter, it won't bring the warning back.)
I much prefer being warned about unused variables and explicitely having to silence those warnings on a case by case basis though - especially when refactoring (one option is to use a wrapper macro MAYBE_UNUSED(bla) macro, or GCC's __attribute__((unused)) or the C++ [[unused]], or the C23 [[maybe_unused]].
But of all those options, "(void)bla;" might actually be the least clutter (and at the same time the most compatible).
I agree that (void)bla is desirably clear, pithy and unambiguous. And I like something like this if I'm dealing with functions with more than a couple unused parameters:
[1] https://inbox.vuxu.org/tuhs/ZKyl8drfW%2FBs1LVa@minnie.tuhs.o...