I have been intending to write down my opinions on the nature of legacy C code, especially mine.
I think that legacy C code seldom conforms to the implicit notions of safety in C.
Much of that code is actually safe however.
I begin this note now because this paper claims the opposite with a good deal of work behind it.
I plan to add comments here about the problem.
2017 February
The CHERI group at the Cambridge have many constructive things to say about how to preserve legacy C programs.
My view, influenced partly by their ideas, is that there is a body of legacy C code that is predicated on a few ideas:
- The computer is 2’s complement.
- Integer arithmetic, (+ — *), is modulo 2n for 3≤n≤6 depending on type.
- The machine address is to the byte.
- A pointer is in fact an integer of either 32 or 64 bits.
It is not mere sloppiness that programs assume this, but to write valid programs that cannot be easily achieved in compliant C.
Other times it is merely a matter of efficiency.
When a pointer is used to fetch or store data, it is up to the logic of the program that the integer that the pointer is, designates a location to which the program should have access.
These programs are not compliant with the C specs but they work correctly on a large variety of today’s machines and are unlikely to be transcribed to compliant C.
The CHERI people suggest a language specification that suits this class of programs.
I agree.
I don’t know that they would agree with my points above.
There is an issue of what to call it.