The Development of the C Language (2003) | Hacker News Reader

The Development of the C Language (2003)

cm.bell-labs.co

191 pointscpeterso24 comments

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

[1] https://inbox.vuxu.org/tuhs/ZKyl8drfW%2FBs1LVa@minnie.tuhs.o...

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...

Wonder who is not. Even cpm … ibm Tso and vm/cms … not to mention unix.

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.

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.

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.

Pretty much exactly one decade after C.

> Amiga OS that was developed in an interim period between BCPL and its successor C

Wut?

BCPL: 1967

C: 1975

Amiga: 1985

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.

And until early 2000's even UNIX systems were lacking fully conforming ANSI/ISO C compilers, e.g. aCC on HP-UX 10, let alone non-UNIX platforms.

Perhaps because compilers were expensive back then.

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.

From the language authors themselves,

"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."

Random dude on Internet, I know better.

From my own recollection, the construction

    (void) var;

for unused variables is specifically to silence certain versions of lint which would otherwise complain.

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.)

That's only in C++. As far as I know in C you need to name all parameters (although maybe that rule has been relaxed in newer versions of C.)

C23 finally relaxes that rule:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2510.pdf

(although some C compilers already allowed it in non-pedantic mode)

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:

    static void unused_(int x, ...) { (void)x; }
    #define unused(...) unused_(0, __VA_ARGS__)

This way you can just have one `unused(foo,bar,baz,quux);` line at the top of the function listing all unused parameters.

(1993)

A real classic!

https://news.ycombinator.com/item?id=36652934

(1993)

huge discussion about this only a few months ago:

https://news.ycombinator.com/item?id=36652934

Reply on news.ycombinator.com