4 ms·

Can you give some examples of language semantics that cannot be expressed in C? One I can think of is doing coroutine / stack swapping stuff. Though even that

Can you give some examples of language semantics that cannot be expressed in C? One I can think of is doing coroutine / stack swapping stuff. Though even that is not insurmountable if your sequential code is rendered into C in a “CPS” style. Another related one is exotic manipulations of the instruction pointer beyond what goto/switch provide. This can be solved too, but inefficiently (put all jump-to-able lines of code in a big switch statement). GCC provides computed goto but that is not standard. In either case, it’s worth pointing out that Rust does not do these types of things and it would be relatively straightforward for a machine to create a 100% semantically equivalent C program from a rust program.

c-cube 6y ago
Naively, I imagine it's hard to implement (efficient) overflow semantics for integers in C, without any UB. Rust provides operators for [wrapping overflow](https://doc.rust-lang.org/nightly/std/primitive.isize.html#method.wrapping_add https://doc.rust-lang.org/nightly/std/primitive.isize.html#m...), [saturating overflow](https://doc.rust-lang.org/nightly/std/primitive.isize.html#method.saturating_add https://doc.rust-lang.org/nightly/std/primitive.isize.html#m...), etc. You can't use UB because then the C compiler can miscompile your code. Semantics of loops might also be tricky. In fact rust struggles with LLVM's optimizer already on some infinite loops because C++ and rust diverge in semantics there.
- CyberRabbi 6y ago
  That’s actually trivial using unsigned arithmetic and two’s complement representation for signed integers, its also equally efficient[1]. Unsigned arithmetic is fully defined in c, including checking for overflow. [1] gcc for example generates optimal code when doing checked addition: https://godbolt.org/z/9jnesx https://godbolt.org/z/9jnesx
  - c-cube 6y ago
    But that's my point; how can you be sure the compiler will emit the right code instead of assuming that the addition does not overflow and then proceed on pruning the test, since overflow on signed integers is not defined?
    - ghoward 6y ago
      You implement it by using unsigned arithmetic, then checking that the sign bit flipped. See https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/arith.h#L305-L315 https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/... . It's a bit more subtle than that, but that is completely devoid of Undefined, Unspecified, and Implementation-Defined Behavior.
    - deleted 6y ago
      [deleted]

c-cube 6y ago

Naively, I imagine it's hard to implement (efficient) overflow semantics for integers in C, without any UB. Rust provides operators for [wrapping overflow](https://doc.rust-lang.org/nightly/std/primitive.isize.html#method.wrapping_add https://doc.rust-lang.org/nightly/std/primitive.isize.html#m...), [saturating overflow](https://doc.rust-lang.org/nightly/std/primitive.isize.html#method.saturating_add https://doc.rust-lang.org/nightly/std/primitive.isize.html#m...), etc. You can't use UB because then the C compiler can miscompile your code. Semantics of loops might also be tricky. In fact rust struggles with LLVM's optimizer already on some infinite loops because C++ and rust diverge in semantics there.

CyberRabbi 6y ago
That’s actually trivial using unsigned arithmetic and two’s complement representation for signed integers, its also equally efficient[1]. Unsigned arithmetic is fully defined in c, including checking for overflow. [1] gcc for example generates optimal code when doing checked addition: https://godbolt.org/z/9jnesx https://godbolt.org/z/9jnesx
- c-cube 6y ago
  But that's my point; how can you be sure the compiler will emit the right code instead of assuming that the addition does not overflow and then proceed on pruning the test, since overflow on signed integers is not defined?
  - ghoward 6y ago
    You implement it by using unsigned arithmetic, then checking that the sign bit flipped. See https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/arith.h#L305-L315 https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/... . It's a bit more subtle than that, but that is completely devoid of Undefined, Unspecified, and Implementation-Defined Behavior.
  - deleted 6y ago
    [deleted]