4 ms·

> "What has stopped people from creating a standard with no undefined behavior? Is such a thing impossible?" I don't understand the "undefined behavior" bandwa

by uasm 7y ago

> "What has stopped people from creating a standard with no undefined behavior? Is such a thing impossible?" I don't understand the "undefined behavior" bandwagon. 1. We have a perfectly defined list of "undefined behaviors". 2. Said list also happens to be relatively small and scoped. 3. "Undefined behaviors" exist because the language can't make certain runtime guarantees which are largely dependent on compiler/os/platform/hardware-specific promises. If you have to, just roll in your own runtime checks. C won't force those on you...

johannes1234321 7y ago
The language could make those guarantees if it wanted to. This might add overhead on some architectures, but would be possible. An example is integer overflow. If we limit to machines using two's complement (thus any machine architecture used during last thirty years) this could be fully defined easily. And if C is ever used on a other architecture they could build a workaround using some form of oberflow trap. (Since CPU design would take C into consideration) Or evaluation order - `i = ++i;` could easily be defined in some way. But might prevent some niche optimisations by the compiler. Of course by C's nature there are limits (C won't be able to detect use after free or similar without changing language notably) but there is room where UB could be reduced, if it was seen as neccisary.
- uasm 7y ago
  > "The language could make those guarantees if it wanted to" > "Of course by C's nature there are limits" You seem to acknowledge the fact that most of the undefined behaviors in C are essentially born out of compromise. Those compromises were driven by principles such as "keep the power in the hands of developers", "don't impose unnecessary restrictions", "keep the language clean", "avoid hidden runtime magic". The end results reflect that. As I've mentioned in my previous comment, there's no "one size fits all", so the language makes it trivial for you to roll out your very own runtime magic (à-la Zig/Nim) which suits you best. Why is that a bad thing?
deleted 7y ago
[deleted]

by uasm 7y ago

johannes1234321 7y ago

The language could make those guarantees if it wanted to. This might add overhead on some architectures, but would be possible. An example is integer overflow. If we limit to machines using two's complement (thus any machine architecture used during last thirty years) this could be fully defined easily. And if C is ever used on a other architecture they could build a workaround using some form of oberflow trap. (Since CPU design would take C into consideration) Or evaluation order - `i = ++i;` could easily be defined in some way. But might prevent some niche optimisations by the compiler. Of course by C's nature there are limits (C won't be able to detect use after free or similar without changing language notably) but there is room where UB could be reduced, if it was seen as neccisary.

uasm 7y ago
> "The language could make those guarantees if it wanted to" > "Of course by C's nature there are limits" You seem to acknowledge the fact that most of the undefined behaviors in C are essentially born out of compromise. Those compromises were driven by principles such as "keep the power in the hands of developers", "don't impose unnecessary restrictions", "keep the language clean", "avoid hidden runtime magic". The end results reflect that. As I've mentioned in my previous comment, there's no "one size fits all", so the language makes it trivial for you to roll out your very own runtime magic (à-la Zig/Nim) which suits you best. Why is that a bad thing?

deleted 7y ago

[deleted]