Re: opinion, ACM Queue: Buffer Overrun Madness

[ljknews <ljknews () mac com>]

At 4:20 PM -0400 6/8/04, der Mouse wrote:
> > > [...] the majority of computer security holes are buffer overruns.
> > > These would be minor irritations but for the world's addiction to
> > > the weakly typed programming languages C and its derivative C++.
>
> Well, actually, but for the world's addiction to sloppy coding.
>
> It's entirely possible to avoid buffer overflows in C; it just requires
> a little care in coding.  C's major failing in this regard - and I
> don't actually consider it all that major - is that it doesn't provide
> any tools to help.  It assumes that you the programmer know what you're
> doing, and the mismatch between that and the common reality is where
> the problem actually comes from.

It is _possible_ to write a correct program in Machine Code,
however a good number of years ago some people (wisely, from my
perspective) decided that automating the correctness effort was
a good idea and Assembly Language was born (over and over again
for various architectures).

This trend was repeated with the advent of Compiled Languages,
intended to describe the problem space more than the machine
space.  There are successive improvements in this automation
of defect avoidance, but some developers have chosen to stop
at a rather weak point in the evolution.

> All that a "better" language will bring you in this regard is that it
> will (a) push the sloppiness into places the compiler can't check and

Not at all.  The "sloppiness into places the compiler can't check"
still exists in C-based languages, and while strongly typed languages
cannot help with certain problems they do free the programmer to deal
with those areas while relying on the computer to check those aspects
that _are_ susceptible to automation.

> (b) change the ways things break when confronted with input beyond the
> design underlying their code.

That seems no different from C-based languages.