Re: Ancient history

Nick Maclaren wrote:
> Douglas A. Gwyn <DAGwyn@null.net> wrote:
>>Nick Maclaren wrote:
>>>Andrew Swallow <am.swallow@btopenworld.com> wrote:
>>>>A simple action is to add a statement saying, "Checks for
>>>>queue/buffer overflows shall be performed and an appropriate
>>>>recovery action performed."
>>>The problem is that nobody knows when such things are legal and
>>>when they are not in C.
>>That's nonsense. It is easy to check for an
>>overflow situation before it occurs.
> Which is orthogonal and irrelevant to my point. If nobody knows where
> the boundary is between overflowing and access to an extended area
> (i.e. permitted use), then it is impossible to insert such checking
> correctly. And that is the case.

That's a vacuous "if". When a programmer codes allocation
of some buffer he knows darn well what its bounds are, and
can easily use that information to check subsequent access.

Just the other day, I ran into another example while
continuing to port the PDP-11 assembler from PDP-11
assembly source code to Standard C. There was code that
kept track of whether each jump/branch would have to
produce branch-over-next-instruction-on-complementary-
condition;jump-to-target or whether it could just use the
limited range branch-to-target-on-condition instead, which
would be more-compact object code. This Boolean choice was
encoded in a bit vector, 8 bits per byte with a static
allocation of 1024 bits. The programmer (presumably Dennis
Ritchie) carefully checked as each jump/branch was seen
whether or not there was room left in the bit vector; if
not, the vector was *not* overrun and the conservative
approach of using the branch-complement;jump sequence was
taken (which always works but is not as compact). Of course
my C translation does the same thing. There is no problem
in avoiding buffer overruns, in assembly language *or* C, if
one knows what he is doing and takes care to do things right.
Received on Thu Sep 29 21:43:55 2005