From mboxrd@z Thu Jan  1 00:00:00 1970
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 31 May 2014 10:19:14 -0400 (EDT)
Subject: [TUHS] Bugs in V6 'dcheck'
Message-ID: <20140531141914.BB15818C0CA@mercury.lcs.mit.edu>

    > From: Ronald Natalie <ron at ronnatalie.com>

    > If I understand what you are saying, it only occurs when you run dcheck
    > with mutliple volumes at one time?

Right, _both_ bugs have that characteristic. But the first one (the
fence-post) only happens in very particular circumstances; the second (the
un-initialized variable) should have happened every time.


    > From: norman at oclsc.org (Norman Wilson)

    > To me it's not surprising at all.
    > On one hand, current examples of widely-distributed critical code
    > containing serious flaws are legion.

What astonished me was not that there was a bug (which I can easily believe),
but that it was one that would have happened _every time they ran it_.

'dcheck' has this list of disks compiled into it. (Oh, BTW, my fixed version
now reads a file, /etc/disks; I am running a number of simulated machines,
and the compiled-in table was a pain.)

So I would have thought they must have at least tried that mode of operation
once? And running it that way just once should have shown the bug. Or did
they try it, see the bug, and 'dealt' with it by just never running it that
way?

	Noel