[TUHS] Minimum Array Sizes in 16 bit C (was Maximum)

[Alexis]

Bakul Shah via TUHS <tuhs at tuhs.org> writes:

> I am still interested in making C safer (to secure as best as 
> possible
> all the zillions of lines of C code in OS kernels). The question 
> is,
> can we retrofit safety features into C without doing major 
> violence to
> it & turning it into an ugly mess? No idea if this is even 
> feasible
> but seems worth exploring with possibly a great ROI.

Related: Ten years ago, Pascal Cuoq, Matthew Flatt, and John 
Regehr
proposed "Friendly C":

> We are not trying to fix the deficiencies of the C language nor 
> making
> an argument for or against C. Rather, we are trying rescue the
> predictable little language that we all know is hiding within 
> the C
> standard. This language generates tight code and doesn’t make 
> you feel
> like the compiler is your enemy. We want to decrease the rate of 
> bit
> rot in existing C code and also to reduce the auditing overhead 
> for
> safety-critical and security-critical C code. The intended 
> audience
> for -std=friendly-c is people writing low-level systems such as
> operating systems, embedded systems, and programming language
> runtimes. These people typically have a good guess about what
> instructions the compiler will emit for each line of C code they
> write, and they simply do not want the compiler silently 
> throwing out
> code. If they need code to be faster, they’ll change how it is
> written.

-- https://blog.regehr.org/archives/1180

Some of the concrete features proposed included:

> 1. The value of a pointer to an object whose lifetime has ended
> remains the same as it was when the object was alive.
>
> 2. Signed integer overflow results in two’s complement wrapping
> behavior at the bitwidth of the promoted type.
>
> 3. Shift by negative or shift-past-bitwidth produces an 
> unspecified
> result.

i seem to recall there have been other proposals in the vein of
"Friendly C", but they're not coming to mind right now.


Alexis.