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

51–60 of 67 posts

Re: A glimpse of undefined behavior in C

#51

Post by ChuckMcM »

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.

Re: A glimpse of undefined behavior in C

#52

Post by thisisnotatest »

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]
No disassembly required.

Re: A glimpse of undefined behavior in C

#53

Post by forgottenpaswrd »

One of the things we train any newcomer to our company is to never do what this man does:a complex single line with expected behavior based on your (arbitrary) conventions.

Yo always do multiple lines, with comments on each one.

It sounds ridiculous, but this simple thing made some kind of bugs impossible: those that you have in front of you but you can't see in a million years. The atomic operation in code is the line, you can't debug a complex line(1).

It is painful forcing people to do that, people use to hate being told what to do, but at the same time they love the outcome so much. In the end everybody loves it.

1.With assembly you are debugging an instance of your code. You are not debugging what will be created with any compiler, any os or architecture.

Re: A glimpse of undefined behavior in C

#54

Post by stinos »

forgottenpaswrd wrote: post #53

One of the things we train any newcomer to our company is to never do what this man does:a complex single line with expected behavior based on your (arbitrary) conventions. Yo always do multiple lines, with comments on each one. It sounds ridiculous, but this simple thing made some kind of bugs impossible: those that you have in front of you but you can't see in a million years. The atomic operation in code is the li…

While I agree the code presented is just, plain and simple, bad, and the first way to the solution is splitting it up, I really don't get why you want comments for every line? Or don't you mean literally every line maybe?

I mean suppose I split the first part of the statement like this:

  int r = a[ i ];
  ++i;
These lines are self-explanatory. It's pretty hard to argue they need a comment? Especially when used in a function that already should have a name/comment explaining what it does?

Re: A glimpse of undefined behavior in C

#56

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.

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

Re: A glimpse of undefined behavior in C

#58

Post by tsahyt »

EpicEng wrote: post #56
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.

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.

Re: A glimpse of undefined behavior in C

#59

Post by natch »

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 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.
Post reply on HN