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

[Joseph S. Myers]

On Mon, 3 Sep 2012, Florian Weimer wrote:

> 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

While I like fat pointers, there was a severe lack of interest in the 
version that was taken out of GCC a decade ago as bitrotten (we'll 
probably take the bitrotten relics out of glibc as well at some point).

> 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

I think you should still care about such overflows as bugs, even if they 
are harder to exploit.

> 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.

For unsigned arithmetic, changes would be massively incompatible with lots 
of existing code; you'd need new non-default facilities (maybe with a 
pragma to enable saturation, for example).

But there's also been very little interest in (for example) making -ftrapv 
work properly (or extending it to cover more problem cases).  And little 
interest in the saturated arithmetic facilities of the Embedded C TR.  
(Personally I think those work the wrong way - saturation should be a 
property of the operations, not the types.  That is, they work the wrong 
way as a language facility, and also the implementation of the language 
facility that does use saturated types should translate the operations to 
use normal types well before they reach the back end.)

Defining and implementing new sets of integer operations is also a large 
amount of work, but at least less risky than things that involve the type 
system; new operations are more or less self-contained without problem 
interactions with the rest of C (beyond defining the circumstances under 
which expressions involving them are or are not constant expressions).

-- 
Joseph S. Myers
joseph@codesourcery.com