Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Falsehoods programmers believe about undefined behavior

predr.ag

Post reply on HN
Print view View original

141–150 of 233 posts

Re: Falsehoods programmers believe about undefined behavior

#141

Post by dooglius »

obi1kenobi wrote: post #126
mnw21cam wrote: post #107

I have a suggestion - it may be completely off the wall, but hear me out. C needs a mechanism to declare in a source file that certain behaviour must be defined, where that behaviour is undefined in the C standard but the target architecture behaves the defined way. Then, when the source is compiled on the target architecture it works as expected, but when compiled on something else it refuses to compile. For example…

Suggestions like this are unfortunately quite infeasible (they fall under the hat of "define all the behaviors"), and the talk I linked in the post goes into why: https://www.youtube.com/watch?v=yG1OZ69H_-o (I'm the post's author.)

I think it's pretty clearly feasible in the specific example GP gave, since -fwrapv does this for GCC and clang. In principle it should be do-able from code level with e.g. 'pragma gcc optimize("frapv")' (but the gcc docs for this say that this feature is for debugging only and doesn't always work).

Re: Falsehoods programmers believe about undefined behavior

#142

Post by obi1kenobi »

naasking wrote: post #134
obi1kenobi wrote: post #126

Earlier quoted context omitted.

Suggestions like this are unfortunately quite infeasible (they fall under the hat of "define all the behaviors"), and the talk I linked in the post goes into why: https://www.youtube.com/watch?v=yG1OZ69H_-o (I'm the post's author.)

He's not trying to define all behaviours, he wants a static assertion that the compiler will compile certain behaviours in a specific way. Seems very different.

That's why I said "falls under the hat of" :) I promise the talk is relevant.

`-fwrapv` is an attempt toward doing such a thing for signed integer overflow specifically. I bet it's a pain to maintain because it significantly increases the surface area of the compiler that needs to be tested.

I don't believe doing this for more cases is feasible at the level of the compiler. Things like CHERI where the hardware and OS help are much more viable, in my book: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Re: Falsehoods programmers believe about undefined behavior

#143

Post by tristan957 »

slicktux wrote: post #132

Divide by zero was one that I always believed would give segmentation fault…but that is totally not the case; I’ve gotten Infinity as a return once… I forget what compiler gives what…

My experience is that you get SIGFPE for division by zero errors.

Re: Falsehoods programmers believe about undefined behavior

#144

Post by obi1kenobi »

chrismorgan wrote: post #21

> Here's the list of guarantees compilers make about the outcomes of undefined behavior: > That's the whole list. No, I didn't forget any items. Yes, seriously. I’m a little disappointed there isn’t an empty or in the middle there. I imagine screen readers would announce something like “list, zero items”.

Post author here. I'm very curious about the screen reader idea. If you or someone else is able to confirm what a good screen reader might do currently / what it might do with an empty list element, I'll happily update the post to whatever is the better behavior.

I wish there were a best practices doc + a matching linter for accessibility things like this.

Re: Falsehoods programmers believe about undefined behavior

#145

Post by marmetio »

mnw21cam wrote: post #107

I have a suggestion - it may be completely off the wall, but hear me out. C needs a mechanism to declare in a source file that certain behaviour must be defined, where that behaviour is undefined in the C standard but the target architecture behaves the defined way. Then, when the source is compiled on the target architecture it works as expected, but when compiled on something else it refuses to compile. For example…

Ada already does something like this. You can choose whether to enable runtime checks, fail to compile, or accept the risk.

The purpose of C is to be easy to implement on new systems. You're never going to get a lot of traction adding anything to C proper.

Re: Falsehoods programmers believe about undefined behavior

#146

Post by tonyarkles »

maccard wrote: post #49
tonetheman wrote: post #17

I am always amazed by articles like these. This guy thoroughly covers this topic. I cannot say I have ever written anything that ran into or caused undefined behavior. And I have programmed for a long time. Is this just an interesting topic or do people actively push the compiler to see what it will do? Maybe I am a boring/simple programmer. :)

> I cannot say I have ever written anything that ran into or caused undefined behavior. And I have programmed for a long time. Assuming you're working with C or C++, you've never: - Dereferenced a pointer? - written a loop with a signed index? - Accessed an index in an array or a vector? - Used a variable? - Used an optimising compiler? Compilers use undefined behaviour in all of the above scenarios as much as possib…

In a similar vein to "dereferenced a pointer", "null check on a pointer" is one of those things that often gets optimized out without the developer realizing it.

Re: Falsehoods programmers believe about undefined behavior

#147

Post by mnw21cam »

adgjlsfhk1 wrote: post #108
mnw21cam wrote: post #102

Earlier quoted context omitted.

Presumably (and really don't take my word for this - I'm a Java bod) the p dereference needs to come before the p NULL check for the p NULL check to be ignored. (Otherwise, how can a NULL check protect a dereference.) And therefore, the NULL check would be unreachable as well, and therefore never executed and not relevant. Please correct my misunderstanding...

Nope, the C spec is just really bad. The NULL check is allowed to be removed.

So the pseudocode:

  if (p is not NULL) {
    dereference p
  }
is UB? That's crazy, but not actually unbelievable.

Re: Falsehoods programmers believe about undefined behavior

#148

Post by asgeir »

haberman wrote: post #110
asgeir wrote: post #104

Earlier quoted context omitted.

The undefined behavior can still affect code generation even though the program gets translated. It's just that the generated code may not do exactly what you expect it to do because the presence of undefined behavior allowed the compiler to make assumptions which may surprise you. edit: It seems that I am incorrect

DR 109 allows that a program may be strictly conforming even if some possible executions of the program invoke UB: > A conforming implementation must not fail to translate a strictly conforming program simply because some possible execution of that program would result in undefined behavior. This text specifically allows for the case that a program is strictly conforming even if there is a possible execution that inv…

It seems that you may be correct.

At the very least I am unable to construct a counter-example so I concede this point

Re: Falsehoods programmers believe about undefined behavior

#150

Post by csours »

Karellen wrote: post #85

It does seem odd to just "lump unspecified behavior and implementation-defined behavior together" in a side-note under the heading of "implementation-defined behaviour", when that term has a precise technical meaning in the C and C++ specifications.

I think that note just means "this post isn't about unspecified or implementation defined behavior". I'm sure you could write articles about each of those.
Post reply on HN