Re: Ancient history

In article <m31x784sba.fsf@lhwlinux.garlic.com>,
Anne & Lynn Wheeler <lynn@garlic.com> wrote:
>
>i've repeatedly claimed in the c-language buffer overlow case ... it
>isn't just the abstraction ... it is the abstraction
>implementation. i'm familiar with some number of pure assembler
>environments ... which have little or no buffer overflows. my
>assertion is that when a human programmer has to manage some
>information ... that area is prone to mistakes. In the c language
>environments ... one such area is storage area lengths ... with the
>result of mistakes that are related to storage area lengths. some
>number of pure assembler environments that have infrastructure
>convention of explicit lengths associated with storage areas have had
>little or none of the typical buffer length related failure modes
>common to large number of c language environments.

All of that is true, and I have similar experiences, but the issue
here IS the abstraction. C's model of arrays and areas of data
is precisely that of a pointer to the start - with no length
included or includable.

It is possible to build an abstraction on top of that which includes
both the pointer and its size, but that is a separate model. Many
of the more robust C programs do precisely that - which is precisely
using C as a semi-portable assembler, as it was designed for.

Regards,
Nick Maclaren.
Received on Thu Sep 29 21:43:10 2005