4 ms·

Wise man once said: "C is just memory, with syntax sugar."

by jb1991 4y ago

1ris 4y ago
for a definiton of "just memory" that includes the strict aliasing rule. Certainly not a buffer of bytes, what most people would assume when they hear "just memory".
- jb1991 4y ago
  The strict aliasing rule that you point out is not part of the “just memory” part, but rather the “syntax sugar” part. Now you can debate if it’s the right kind of sugar, however.
  - 1ris 4y ago
    No, The strict aliasing part of the semantic of the memory. “syntax sugar” is, per definition, part of the syntax.
    - gpderetta 4y ago
      Indeed. What the strict aliasing rule implies is that only well typed C programs have meaning. Which means that C is indeed not "just memory". If C was just memory, the only operations allowed would be on and through memory addresses, and values wouldn't be first class.
      - jstimpfle 4y ago
        "Memory" might not even be a concept in the C standard, rather it is what C programmers think about in practice. The culture around the language is that the language should get out of the way as much as possible while still providing a good amount of convenience, portability, and performance. The standard is a necessity, but is not the center of attention while working.
      - int_19h 4y ago
        But then there's the memcpy escape hatch that lets you treat anything and everything as a raw sequence of bytes with no concern for types or aliasing. So arguably the fundamental memory model is still "just memory" (albeit not necessarily a single address space), and the rest is bolted on top and applies only to specific language constructs.
dfox 4y ago
One of the main consequences of how the abstract machine in the standard is defined is that it does not imply that there is one big flat memory. It requires pointers into arrays to behave as if there was, but that is it. In other words, taking a ptr_diff_t of two pointers that do not point into the same array is UB (6.5.6.10). Trivial example of platform where that is relevant is 16b 8086 with anything but tiny memory model (ie. CS=DS=SS). Somewhat more relevant are various Harvard-ish embedded platforms with separate RAM/ROM address spaces. In both cases there are C implementations that are used in production applications. Another reason for this rule (and probably the original one) are various platforms with segmentation based fine-grained memory protection. That means either things like Burroughs large systems or running C on top of some kind of VM while preserving the underlying memory management. And there are C implementations for that kinds of environments (That most of the existing C code is not directly compatible with that kind of implementation is another thing).
- pjc50 4y ago
  Another thing that turns out to be compatible with the C memory model is "doing weird things with pointer bits", such as pointer authentication: https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/pointer-auth-v7.pdf https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets...

Wise man once said: "C is just memory, with syntax sugar."

by jb1991 4y ago

Wise man once said: "C is just memory, with syntax sugar."

1ris 4y ago

for a definiton of "just memory" that includes the strict aliasing rule. Certainly not a buffer of bytes, what most people would assume when they hear "just memory".

jb1991 4y ago
The strict aliasing rule that you point out is not part of the “just memory” part, but rather the “syntax sugar” part. Now you can debate if it’s the right kind of sugar, however.
- 1ris 4y ago
  No, The strict aliasing part of the semantic of the memory. “syntax sugar” is, per definition, part of the syntax.
  - gpderetta 4y ago
    Indeed. What the strict aliasing rule implies is that only well typed C programs have meaning. Which means that C is indeed not "just memory". If C was just memory, the only operations allowed would be on and through memory addresses, and values wouldn't be first class.
    - jstimpfle 4y ago
      "Memory" might not even be a concept in the C standard, rather it is what C programmers think about in practice. The culture around the language is that the language should get out of the way as much as possible while still providing a good amount of convenience, portability, and performance. The standard is a necessity, but is not the center of attention while working.
    - int_19h 4y ago
      But then there's the memcpy escape hatch that lets you treat anything and everything as a raw sequence of bytes with no concern for types or aliasing. So arguably the fundamental memory model is still "just memory" (albeit not necessarily a single address space), and the rest is bolted on top and applies only to specific language constructs.

dfox 4y ago

One of the main consequences of how the abstract machine in the standard is defined is that it does not imply that there is one big flat memory. It requires pointers into arrays to behave as if there was, but that is it. In other words, taking a ptr_diff_t of two pointers that do not point into the same array is UB (6.5.6.10). Trivial example of platform where that is relevant is 16b 8086 with anything but tiny memory model (ie. CS=DS=SS). Somewhat more relevant are various Harvard-ish embedded platforms with separate RAM/ROM address spaces. In both cases there are C implementations that are used in production applications. Another reason for this rule (and probably the original one) are various platforms with segmentation based fine-grained memory protection. That means either things like Burroughs large systems or running C on top of some kind of VM while preserving the underlying memory management. And there are C implementations for that kinds of environments (That most of the existing C code is not directly compatible with that kind of implementation is another thing).

pjc50 4y ago
Another thing that turns out to be compatible with the C memory model is "doing weird things with pointer bits", such as pointer authentication: https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/pointer-auth-v7.pdf https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets...