1 Oct
2024
1 Oct
'24
3:42 a.m.
Bakul Shah via TUHS <tuhs(a)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.