3 ms·

I really wish both would be valid in C11. Or rather I wish I had "systems-C" where all the undefined behaviour added for high performance computing was filed of

by Asooka 4y ago

I really wish both would be valid in C11. Or rather I wish I had "systems-C" where all the undefined behaviour added for high performance computing was filed off and defined as "whatever the platform does".

masklinn 4y ago
> all the undefined behaviour added for high performance computing UBs were added for cross-incompatibilities, where operations were too "core" (and / or untestable) for IBs to be acceptable. The reason was not performance (aside from not imposing a runtime check where that would have been possible) but portability: > 3.4.3 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements Those UBs were leveraged later on by optimising compilers, because they provide constraints compensating for C's useless type system. So you can just use a non-optimising compiler or one which only does simple optimisations (e.g. tcc), and see what the compiler generates from your UBs.
- tsimionescu 4y ago
  The standard also has implementation-defined behavior, doesn't it?
  - masklinn 4y ago
    Their existence is mentioned in my comment so I am not sure what you are trying to say.
int_19h 4y ago
Any given implementation is free to define any particular instance of UB. "Whatever the platform does" is still UB for portable code though, since the set of possible platforms and their behavior is unbounded.
pcwalton 4y ago
> Or rather I wish I had "systems-C" where all the undefined behaviour added for high performance computing was filed off and defined as "whatever the platform does". Depending on what you mean by undefined behavior, now you've made register allocation an invalid optimization. You really don't want to use that version of C.
oconnor663 4y ago
I think volatile variables are a good example of how we really don't want to rely on platform semantics most the time. We use volatile variables to tell the compiler "hey, the platform actually cares about these writes, so do them the way I wrote them."* But this is relatively rare! The vast majority of the time, we want the compiler to go nuts with constant propagation and reordering and all the other good stuff. A language where volatile was the default and "go nuts" was an explicit keyword would be really annoying to use. * There are more things in heaven and earth (MMIO!) than are dreamt of in your memory model.

by Asooka 4y ago

masklinn 4y ago

> all the undefined behaviour added for high performance computing UBs were added for cross-incompatibilities, where operations were too "core" (and / or untestable) for IBs to be acceptable. The reason was not performance (aside from not imposing a runtime check where that would have been possible) but portability: > 3.4.3 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements Those UBs were leveraged later on by optimising compilers, because they provide constraints compensating for C's useless type system. So you can just use a non-optimising compiler or one which only does simple optimisations (e.g. tcc), and see what the compiler generates from your UBs.

tsimionescu 4y ago
The standard also has implementation-defined behavior, doesn't it?
- masklinn 4y ago
  Their existence is mentioned in my comment so I am not sure what you are trying to say.

int_19h 4y ago

Any given implementation is free to define any particular instance of UB. "Whatever the platform does" is still UB for portable code though, since the set of possible platforms and their behavior is unbounded.

pcwalton 4y ago

> Or rather I wish I had "systems-C" where all the undefined behaviour added for high performance computing was filed off and defined as "whatever the platform does". Depending on what you mean by undefined behavior, now you've made register allocation an invalid optimization. You really don't want to use that version of C.

oconnor663 4y ago

I think volatile variables are a good example of how we really don't want to rely on platform semantics most the time. We use volatile variables to tell the compiler "hey, the platform actually cares about these writes, so do them the way I wrote them."* But this is relatively rare! The vast majority of the time, we want the compiler to go nuts with constant propagation and reordering and all the other good stuff. A language where volatile was the default and "go nuts" was an explicit keyword would be really annoying to use. * There are more things in heaven and earth (MMIO!) than are dreamt of in your memory model.