4 ms·

The crux of the argument of this article seems to be that C allows working directly with raw memory, which is necessary for some low-level tasks, such as commun

The crux of the argument of this article seems to be that C allows working directly with raw memory, which is necessary for some low-level tasks, such as communication with memory-mapped devices. This is not possible in pure managed language, due to the additional level of abstraction. However, the author themselves state that this is not something that implies that undefined behavior are unavoidable when working close to the metal: In fact, the very “unsafety” of C is based on an unfortunate conflation of the language itself with how it is implemented. Working from first principles, it is not hard to imagine a safe C.13 As Krishnamurthi and Felleisen [1999] elaborated, safety is about catching errors immediately and cleanly rather than gradually and corruptingly I would say that, what they are describing is essentially what Rust has achieved, or at least what it is meant to do.

quackulus 3y ago
Any good docs on memory and data structures for c?
steveklabnik 3y ago
While I don't fully disagree with you, I think the author would disagree. This line of argument is also repeated in recent C++ standards papers around "safety," that is, this argument is explicitly saying "memory safety != safety, and safety is more important, and therefore focus on memory safety is bad for safety." I have two responses to this that aren't "back on script." > it is not hard to imagine (from your quote) Sure, we can imagine this language, but it does not exist. Yes in theory maybe if we all did what the author said, C could be that language, but it is simply not today. When people say "C" they mean the C that actually exists, not an alternative implementation that would technically conform to the standard. Pushes have been made in this direction a number of times, from a number of different people, yet the market has spoken. Second, > Consider unchecked array accesses. Nowhere does C define that array accesses are unchecked. It just happens that implementations don’t check them. This is an implementation norm, not a fact of the language. This is just factually incorrect. Let's examine both C89: https://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf https://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf and C99: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf > J.2 Undefined behavior > An array subscript is out of range, even if an object is apparently accessible with the given subscript (as in the lvalue expression a[1][7] given the declaration int a[4][5]) (6.5.6). It is literally defined as undefined behavior. While sure, that does mean a particular compiler could implement and document semantics for this, it's by definition not portable, because it is stated as such by the standard.
quelsolaar 3y ago
C, is high level language that happens to map really well to hardware. Much of UB is UB simply because it difficult to effectively detect when something goes in to a state of UB. Writing to a memory address can be done in one instruction, but figuring out if that address is legal to write to is a slow and complicated process. The C standard let an implementation ignore that problem, but it is also does not stopping the implementation from making sure the address is valid before writing to it. Almost no one tries to make such an implementation, because the users have decided they would rather have speed, but anyone can write a ISO compliant implementation without any UB if that's what they want.
- bandrami 3y ago
  It maps well to hardware from the 1970s and 1980s. It has very little to do with modern hardware, and for that matter modern hardware does some somersaults to present an interface that C "expects".
  - _rubs 3y ago
    What are the specific differences?
    - throwaway17_17 3y ago
      The easiest read on this topic is Chris Chisnall’s ‘C is not a Low Level Language’ article [1]. It is a good read in general and not all that long. It addresses vectors, out-of-order execution, pipelining, and plenty of other topics along the way. 1 - https://dl.acm.org/doi/10.1145/3212477.3212479 https://dl.acm.org/doi/10.1145/3212477.3212479
  - quelsolaar 3y ago
    Modern hardware is designed to map to C rather than the other way around. Turns out people want to buy hardware that can run existing software.
fulafel 3y ago
Communication with memory-mapped devices actually works pretty well in other languages. And surprisingly badly in C: when trying to directly use memory mapped space as backing store for C objects, compilers have freedoms about the memory accesses, which doesn't mix well with finicky mmio devices. (There are also platform differences which make this pretty nonportable). Reads and writes to memory mapped devices can be represented as eg function calls in other languages (and commonly in C too).

quackulus 3y ago

Any good docs on memory and data structures for c?

steveklabnik 3y ago

While I don't fully disagree with you, I think the author would disagree. This line of argument is also repeated in recent C++ standards papers around "safety," that is, this argument is explicitly saying "memory safety != safety, and safety is more important, and therefore focus on memory safety is bad for safety." I have two responses to this that aren't "back on script." > it is not hard to imagine (from your quote) Sure, we can imagine this language, but it does not exist. Yes in theory maybe if we all did what the author said, C could be that language, but it is simply not today. When people say "C" they mean the C that actually exists, not an alternative implementation that would technically conform to the standard. Pushes have been made in this direction a number of times, from a number of different people, yet the market has spoken. Second, > Consider unchecked array accesses. Nowhere does C define that array accesses are unchecked. It just happens that implementations don’t check them. This is an implementation norm, not a fact of the language. This is just factually incorrect. Let's examine both C89: https://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf https://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf and C99: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf > J.2 Undefined behavior > An array subscript is out of range, even if an object is apparently accessible with the given subscript (as in the lvalue expression a[1][7] given the declaration int a[4][5]) (6.5.6). It is literally defined as undefined behavior. While sure, that does mean a particular compiler could implement and document semantics for this, it's by definition not portable, because it is stated as such by the standard.

quelsolaar 3y ago

C, is high level language that happens to map really well to hardware. Much of UB is UB simply because it difficult to effectively detect when something goes in to a state of UB. Writing to a memory address can be done in one instruction, but figuring out if that address is legal to write to is a slow and complicated process. The C standard let an implementation ignore that problem, but it is also does not stopping the implementation from making sure the address is valid before writing to it. Almost no one tries to make such an implementation, because the users have decided they would rather have speed, but anyone can write a ISO compliant implementation without any UB if that's what they want.

bandrami 3y ago
It maps well to hardware from the 1970s and 1980s. It has very little to do with modern hardware, and for that matter modern hardware does some somersaults to present an interface that C "expects".
- _rubs 3y ago
  What are the specific differences?
  - throwaway17_17 3y ago
    The easiest read on this topic is Chris Chisnall’s ‘C is not a Low Level Language’ article [1]. It is a good read in general and not all that long. It addresses vectors, out-of-order execution, pipelining, and plenty of other topics along the way. 1 - https://dl.acm.org/doi/10.1145/3212477.3212479 https://dl.acm.org/doi/10.1145/3212477.3212479
- quelsolaar 3y ago
  Modern hardware is designed to map to C rather than the other way around. Turns out people want to buy hardware that can run existing software.

fulafel 3y ago

Communication with memory-mapped devices actually works pretty well in other languages. And surprisingly badly in C: when trying to directly use memory mapped space as backing store for C objects, compilers have freedoms about the memory accesses, which doesn't mix well with finicky mmio devices. (There are also platform differences which make this pretty nonportable). Reads and writes to memory mapped devices can be represented as eg function calls in other languages (and commonly in C too).