Re: Request for comments on language extension: Safe arrays and pointers for C.

[James Dennett <james dot dennett at gmail dot com>]

On Fri, Aug 31, 2012 at 2:55 PM, John Nagle <nagle@animats.com> wrote:
>    We have proposed an extension to C (primarily) and C++ (possibly)
> to address buffer overflow prevention.  Buffer overflows are still
> a huge practical problem in C, and much important code is still
> written in C.  This is a new approach that may actually work.
>
> The proposal,
> "Safe arrays amd pointers for C, round 2", is here:
>
> http://www.animats.com/papers/languages/safearraysforc41.pdf
>
> This has been discussed on Lambda the Ultimate and comp.std.c,
> and the flaws found in those discussions have been dealt with.
> So far, no one has found a killer reason why this can't work.
>
> The proposal is to combine the concepts of C variable length
> array formal parameters and C++ references.  This allows
> passing arrays as arrays, rather than pointers.

Could you say a little more of why it appears necessary to introduce
references into C for this?  The reason I'm puzzled is that C already
has the ability to pass arrays in a way that preserves their size
(just pass the address of the array) -- what is it that references
change in this picture that justifies such a radical change?  Could we
just permit pointer-to-array-of-n elements to convert to
pointer-to-array-of-(n-1) elements, and/or provide some way to slice
explicitly?

Of course to make this succeed you'll need buy-in from implementors
and of the standards committee(s), who will need to trust that the
other (and therefore that users) will find this worth the cost.  It
generally takes a lot of work (in terms of robust specification and
possibly implementation in a fork of an open source compiler or two)
to generate the consensus necessary for a proposal to succeed.
Something that might ultimately seek to change or even disallow much
existing C code has an even higher bar -- getting an ISO committee to
remove existing support is no small achievement (e.g., look at how
long gets() persisted).

I'd love to see a reduction in the number of buffer overruns that are
present in code, but it's an uphill struggle.

-- James