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 jos...@codesourcery.com
