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

[Larry McVoy via TUHS]

On Wed, May 27, 2026 at 11:50:34AM -0400, Dan Cross wrote:
> On Tue, May 26, 2026 at 10:02???AM Larry McVoy via TUHS <tuhs at tuhs.org> wrote:
> > [snip BLS's comments about cars, instruments, and programs]
> > Amen to all of this.  And I think I've posted this but it is worth a repeat
> > since you mentioned sports cars.
> >
> > When Travis was looking at C, I told him that C is like driving a sports
> > car on a narrow, twisty road with no guard rails and a there is a cliff
> > on one side of the road.  So it is not for people who want to look at their
> > phone while driving, that's how you die.  On the other hand, if you are a
> > good driver, that narrow, twisty road and that car are glorious.
> 
> But you have also said that if you take someone out on your boat, and
> they won't wear a flotation device, that's the last time they're going
> out on your boat.

Yep.  It's a liability thing, if I don't get them home safe, I can be
sued for loss of life.

> If the sports car goes off the side of the mountain, 99 times out of
> 100 the only one who ends up in the morgue is the driver: tragic,
> perhaps, but one's own damn fault. On the other hand, if the school
> bus goes off the road, the consequences are far worse. Most of the
> time software is Not a sports car; it's more like a school bus loaded
> with kids.

Fair point.

> On the other hand, it's super easy to inadvertently stumble into
> undefined behavior and segfaults, even in extremely well-written C.
> Here's an example from the bitkeeper source. I randomly looked at
> https://github.com/bitkeeper-scm/bitkeeper/blob/master/src/port/bkd_server.c,
> and notice the following on lines 58 and 59:
> 
> ```
> |        while (nav[i++] = av[j++]);
> |        assert(i < 100);
> ```

We have regression tests that throw all sort of random noise at every bk
command.

> Here, the contents of the string array `av` are copied into `nav`,
> which is defined as, `char *nav[100];`. Near as I can tell, this is
> called directly with an only slightly-modified version of the
> arguments to `main`, but nothing checks that the input argument vector
> will not overflow `nav` before the loop.  The `assert` is obviously
> meant to catch this, but since it happens _after_ the loop, by the
> time you run into it, you've probably already clobbered what was
> around `nav` on the stack; indeed, I can trigger this on a local
> build, and the resulting stack frame is junk.  Moreover, the code as
> written is wrong: the array has space for 100 elements, thus indices
> 0..99 are valid. Suppose that i==99'th element is the terminating nil
> pointer, then the `i++` index expression would set nav[99] and then
> set i to 100; that's perfectly valid, but in that case, the `assert`
> will still fire: that is, the last element in `nav` is inaccessible as
> written.

And yet, that code has been running for decades with out problems.  Yeah,
it could be cleaner, but we had other work to do.  You are all worked up
about a non-problem.

> Of course, this is kind of a silly example: only a jerk is going to
> give more than 100 arguments to `bk` in order to trigger this bug, but
> the point is, you're going to invariably find this kind of thing in
> _any_ large C code base, even ones written by legitimate experts
> extremely familiar with the language.

Indeed.  Except it was not ever a problem.  Your stance reminds me a little
of Bart Miller's fuzz paper.  Yep, you pass random garbage to every program
in /usr/bin and you will find all sorts of bugs.  But is that useful 
information if everyone is using those programs without triggering those
bugs?

Back in the day, Coverity used BitKeeper and we got to use their tool on
our source base.  It was useless, it found all sorts of stuff, but it was
all like your example, a bug in theory but not in practice.  If it had
found any real bugs, we would have been pleased.  It did not.

You are welcome to Rust, given the caliber of many programmers today, I can
see the value.  I took a different approach, we hired excellent programmers
and our stuff worked.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat