If a standard document uses C code to describe std behavior, but that C code relies on UB, may an implementation do whatever they want?
-
-
Replying to @oe1cxw @RichFelker
In C and C++ std documents notes and examples are non-normative so if they contradict normative text that is a mistake or a defect
1 reply 0 retweets 0 likes -
Replying to @shafikyaghmour @RichFelker
You misunderstood my tweet. I am not talking about the C or C++ standard documents.
1 reply 0 retweets 0 likes -
I'm also not talking about examples. I'm talking about standards that use C code for the (only) definition of the standardized behavior.
1 reply 0 retweets 0 likes -
Replying to @oe1cxw @shafikyaghmour
If you count RFCs as standards there are probably lots more examples of this.
1 reply 0 retweets 2 likes -
My immediate thought: someone please go and find some UB in libopus
1 reply 0 retweets 1 like -
Replying to @erincandescent @oshepherd and
the problem with UB is that relying on it (in one place or another) is nearly inescapable in code which "actually does anything useful"...
1 reply 0 retweets 0 likes -
Replying to @cr88192 @oshepherd and
No, that's a common misconception. It's mostly sloppiness, along with a small but nonzero amount of willful wrongness.
1 reply 0 retweets 1 like -
Replying to @RichFelker @cr88192 and
If you actually want to express wrapping signed arithmetic (rare that it's wanted) there are easy, zero-cost ways to express it without UB.
1 reply 0 retweets 1 like -
Replying to @RichFelker @oshepherd and
you mean using unsigned and casts?... maybe. I was thinking for example signed ((x<<31)>>31) and similar, (x/(1<<31)) may use a divide, ...
2 replies 0 retweets 0 likes
Not sure I understand your examples but they look like places you want an unsigned data type with a "sign-extending right shift" operator.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.