Some Were Meant for C

https://www.cs.kent.ac.uk/people/staff/srk21//research/papers/kell17some-preprint.pdf

• The C language is used for: writing application and writing system code (“communicative”)
• For both parts performance is not THAT needed
• It has a lot of problems. Then why is it so popular?
• Several possible explanations:
  • “C” values simplicity, tolerates incorrectness, inconsistency and incompleteness
  • Only “C” allows to write a “communicative code” to allow several solutions to work together. Memory - is a “communication channel”
  • E.g. you can implement a function to call callbacks from some memory blocks: void (*cb)(“some args”)
  • It can be JIT-compiled regions, code compiled from other languates, etc
  • “C” chooses not to encapsulate everything, but rather have some agreement between all participants (ABI)
• Why “C” is not safe?
  • “Managed” memory (= safe memory management) always mean working inside our own memory.
  • All languages have “unsafe” instructions (including Rust, Haskell)
  • “Communication” level requires to work with not “our own memory” => unsafe.
  • What is “safe” language (!!!!!):
    • Catching errors immediately and cleanly rather than gradually and corruptingly
    • Behaviour of any program can be easily understood in terms of the source-level language semantics
  • But “safety” is possible! Not in language spec, but in language implementationk:
  • Check casting, have some tags in every pointer, properly check casting.
  • Temporal safety is possible (=> pointer to paper)
  • “Nowhere does C define that array accesses are unchecked… implementations don’t check it”
  • Overrunning pointer into some other object - undefined behaviour. Should catch this errors
  • META-level (meta-circular), when the next level adds some additional abstraction (“define simple c compiler” to compile “usual c”)- possible to be safe
• Undefined, Unspecified, Implementation-specific
  • Undefined is not to optimize anything. It means that the error can’t be detect in all possible cases
• IMHO:
  • It is not a “technical paper”. It should have been said in the very beginning!
  • Could be shortened at least twice! Sometimes it is difficult to read (one sentence per paragraph, repetitions, etc)
  • I can’t agree that safety should not be specified in the language spec (instead - in implementation). If you don’t specify anything in spec, it won’t survive.