Re: Ancient history

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> In either case there is some overhead to actually doing it.
> That seems to be the biggest reason not to do it.

generalized bounds checking there is ... but as been demonstrated in
extremely performance sensitive, purely assembler based infrastructure
... it is possible to have a pointer+length abstraction and use it
majority of buffer/storage related operations with little observable
overhead ... aka all operations that otherwise use some sort of
length-based operations and all libraries and infrastructure
operations that operate on collections of characters or bytes (as
opposed to lower-level per byte/character checks).

have the explicit length for use by all existing length oriented
operations ... and, in addition utilizing the length abstraction for
all operations that deal with collections of bytes/characters ... goes
a long way to eliminating the majority of length related failures
... with little or no measureable increase in overhead.

frequently the biggest reason for not doing it ... is it is a change;
and it seems that frequently worst case performance issues are raised
in support of not needing change.

frequently infrastructures will have tens of thousand instruction
pathlength for dealing with a specific byte/character collection ...
and adding a couple more instructions for length checking for the
couple dozen operations that might involve things like copying or
moving a byte/character collection from one storage area to another
storage area .... will be totally lost in the noise.

such a change might not be 100 percent full proof against all possible
buffer related programming mistakes ... but it might possibly handle
99.9999 percent of the existing buffer length associated exploits.

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/