[TUHS] [COFF] Re: Re: [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available?

[Jeffrey H. Johnson via TUHS]

I'm going to jump in here and say that it is absolutely possible
to write perfectly good C code that doesn't have these kinds of
bugs or issues that is also incredibly portable, free of all
undefined behaviors, and can run on every platform, including the
really weird ones, and anyone who says it doesn't or you can't
do so is cutting corners.

Does it take a lot more time and discipline, yes.  It also takes
a lot longer to accomplish a lot less, but C absolutely gives
you the tools you need to produce bug-free code.

In fact, if you really want to get into it, you can produce code
that is not only bug-free, but tools exist in the formal verification
realm that allow you to prove mathematically the absence of bugs,
including memory safety, in C code.

You can take a look at this CRC utility that I recently wrote,
because it's more an example of how I would a write universally
portable utility of this type that's intended to be bug-free, but
not going to the expense of formal verification to make it provably
so.

https://gitlab.com/dps8m/crc

It was carefully constructed to be portable and correct on every
platform with a standard s-onforming C compiler.

It works equally on ancient pre‑ANSI / "C86" / K&R C compilers,
environments providing deficient stdio implementations, environments
with broken (or completely missing) division or modulo math operations,
systems where NULL is not equal to zero (e.g. Honeywell 600/6000‑series),
systems using one's‑complement integer representation (e.g., Unisys
ClearPath Dorado / OS 2200 with UCS C), systems with character sizes
other than 8 bits (e.g., DEC PDP‑10, H6000, Unisys), and systems using
non‑ASCII character sets (e.g., IBM mainframes, Unisys MCP), or even
systems using non-ASCII/non-EBCDIC character sets.  It has it's own
internal implementation of arbitrary precision math code that's slow
but stable that I use elsewhere.

It only needs the C compiler to provide one storage type with a width at
least as wide as the 32‑bit CRC.  Even compilers for the Commodore 64 and
Apple II such as Vbcc can fit the bill here.

It supports systems with characters types of least 8 bits, but is happy
with 9 bits, or 12 bits, 17-bit bit or even 32-bit chars.

The same source file works on Multics, TOPS-20, CP/M-86, CP/M-80,
MS-DOS, Windows, ELKS, Atari ST, Amiga, and every UNIX system, and
really should be free bugs and undefined behavior on all platforms.

C can do it all.

--
Jeffrey H. Johnson
trnsz at pobox.com