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
