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

[Florian Weimer]

On 08/31/2012 11:55 PM, John Nagle wrote:

> The proposal,
> "Safe arrays amd pointers for C, round 2", is here:
>
> http://www.animats.com/papers/languages/safearraysforc41.pdf

The typedef at the top of page 9 is incorrect or needs an explanation. 
At the top of page 13, the example references an "itemproto" identifier, 
but it doesn't seem to have been defined earlier.

I disagree with the conclusion: this proposal does not address a 
category of computer program crashes—actually, it makes programs crash 
in a deterministic manner which could have worked before most of the 
time!  The honor of causing most crashes probably belongs to NULL 
pointer dereferences, not out-of-bounds array accesses.  (It's just the 
conclusion which is misleading, this is not intended as a criticism of 
the proposal as such.)

But my I real concern is that this proposal does not go far enough and 
does not address a sufficiently large subset of memory safety issues, 
compared to its implementation costs.  Part of that is related to the 
reluctance to use fat pointers (although they are implicit in some 
places, such as the return value of array_slice).  Code can write to 
length parameters and struct fields (as the string library in appendix 2 
does), and this can thwart any safety guarantees.  With structs, there 
is also the issue of aliasing.

Most worrying to me is the lack of a solution for integer overflows. 
For example, sstring_alloc in the example can return a pointer to a 
struct whose trailing array is smaller than the length field indicates. 
  At present, I think that you either need full memory safety à la Java 
(so you don't have to care about integer overflows), or changes in 
integer arithmetic.  Whether it should trap, saturate, or do something 
else entirely (e.g., comparison operators always return a result as if 
all arithmetic operations on both sides of the equation were carried out 
over the rationals), is a different question.  But I have a strong 
feeling (not yet backed by data, though) that limited memory safety 
without changes to integer arithmetic will not buy us much.

(Oh, and VLAs will never be first-class types in C++, so I'm not sure if 
it is a good idea to promote their use.)

-- 
Florian Weimer / Red Hat Product Security Team