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

A glimpse of undefined behavior in C

blog.chris-cole.net

Post reply on HN
Print view View original

61–67 of 67 posts

Re: A glimpse of undefined behavior in C

#61

Post by ajanuary »

natch wrote: post #59

What an annoying post. Talks like he knows a lot, when he doesn't know this most basic of basic points of how C works. It's understandable to not know everything, even to have the odd hole in your basics like this. But the know-it-all voice (and for such a basic topic) "I explained operator precedence..." is just going to make you someone nobody wants to work with. This is not undefined behavior, it's one of the firs…

It's a common stylistic choice. Exaggerate how arrogant and smart you thought you were, only for it to be pricked by reality, end up humbled.

Re: A glimpse of undefined behavior in C

#62

Post by clarry »

natch wrote: post #59

What an annoying post. Talks like he knows a lot, when he doesn't know this most basic of basic points of how C works. It's understandable to not know everything, even to have the odd hole in your basics like this. But the know-it-all voice (and for such a basic topic) "I explained operator precedence..." is just going to make you someone nobody wants to work with. This is not undefined behavior, it's one of the firs…

> This is not undefined behavior, it's one of the first things you learn about C after encountering the pre/postfix operators IF you pay attention to the details, which, with C, you should know to do.

What exactly is not undefined behavior? The post describes a statement where a variable is modified multiple times between sequence points. What does the standard say about this?

N1256, 6.5 says

  Between the previous and next sequence point an object
  shall have its stored value modified at most once by the
  valuation of an expression.
J.2 Undefined behavior

  The behavior is undefined in the following circumstances:
  [..]
  * Between two sequence points, an object is modified more
    than once, or is modified and the prior value is read
    other than to determine the value to be stored (6.5).
What's with the know-it-all voice?

Re: A glimpse of undefined behavior in C

#63

Post by ygra »

twoodfin wrote: post #49
brihat wrote: post #33

Isn't this actually called "implementation-defined" behaviour in the std rather than "undefined" behaviour? I generally get a segfault for undefined behaviors

It's undefined. That means the compiler and runtime can choose to segfault, do something that looks right, silently corrupt your program, launch the nuclear missiles, whatever. And there's no requirement that this behavior be repeatable, so the code can work with debug flags turned on but fail in a release build. You can never rely on your compiler's implementation of undefined behavior.

> You can never rely on your compiler's implementation of undefined behavior.

I wish I could somehow get my coworker to understand this. He's mostly "Yeah, well, I know it's undefined, but there's really no way this could be anything else than . I know what the CPU does there."

Re: A glimpse of undefined behavior in C

#64

Post by Perseids »

thisisnotatest wrote: post #52

Aside: this test code would have been a bit easier to debug if it had used decimal bases. That is, replace int a[] = {10,20,30}; int r = 1 * a[i++] + 2 * a[i++] + 3 * a[i++]; with int a[] = {1,2,3}; int r = 1 * a[i++] + 10 * a[i++] + 100 * a[i++]; Then if your program outputs r = 111, it's obvious that it's doing a[0] + 10*a[0] + 100*a[0] and if it outputs 321, it's obvious that it's doing a[0] + 10*a[1] + 100*a[2] N…

Alternatively just think a moment longer and realize that the lower limit of each value (10) already produces 60 and thus each must must be 10.

Re: A glimpse of undefined behavior in C

#65

Post by EpicEng »

ChuckMcM wrote: post #51

Interesting, my first guess would have been '60' since the old C89 / K&R C had the behavior (prefix ops) => ( statement ) =>(postfix ops) Which made code like *a++ = *b--; Change the pointers after the copy as opposed to having them change before the copy. It is interesting that this has become compiler defined.

Also, it's not implementation ("compiler") defined, it's undefined behavior.

Re: A glimpse of undefined behavior in C

#66

Post by EpicEng »

tsahyt wrote: post #58
EpicEng wrote: post #56

Earlier quoted context omitted.

It hasn't. You're not modifying a single variable twice within a single sequence point in that example.

That's really all there is to it, isn't it? I've never understood why some people feel the urge to modify the same variable multiple times in the same statement. It doesn't help readability, it's harder to reason about and worst of all leads you directly into the land of undefined behavior, where everything that can go wrong, will go wrong.

Yeah, the need to shove as much code as possible into one line seems to go away with experience. Once you have to debug and maintain that crap you realize very quickly that one liners are not necessarily something to strive for.

Re: A glimpse of undefined behavior in C

#67

Post by tsahyt »

EpicEng wrote: post #66
tsahyt wrote: post #58

Earlier quoted context omitted.

That's really all there is to it, isn't it? I've never understood why some people feel the urge to modify the same variable multiple times in the same statement. It doesn't help readability, it's harder to reason about and worst of all leads you directly into the land of undefined behavior, where everything that can go wrong, will go wrong.

Yeah, the need to shove as much code as possible into one line seems to go away with experience. Once you have to debug and maintain that crap you realize very quickly that one liners are not necessarily something to strive for.

I used to strive for clever solutions. The shorter the better. I still like to look at them but I want them as far away as possible from my code base. Sure, if a solution is clever and efficient, while still readable, maintainable and easy to understand when documented properly, I'd use it. However, my general rule of thumb these days is: "Write this code, so an utter idiot can read it". Because that's what's going to happen: One day I'll have to read it again, and I'll feel like an idiot, trying to understand what once went through my brain.

That's something that took me way too long to learn and I feel that novice programmers should embrace that more. We all like to feel like Einstein sometimes, but a big code base is not the place for solutions only we can understand... temporarily.

Post reply on HN