4 ms·

I was taking about the ability to debug code. Various IDEs/compilers have sometimes issues and bugs on multistatement lines in DWARF/etc. I've worked on a low l

I was taking about the ability to debug code. Various IDEs/compilers have sometimes issues and bugs on multistatement lines in DWARF/etc. I've worked on a low level debugger, so it was a big problem, even few years back.

akkartik 10y ago
Fair enough. But where do you see multistatement lines in the link?
- quickben 10y ago
  For example: https://github.com/martanne/vis/blob/master/buffer.c https://github.com/martanne/vis/blob/master/buffer.c bool buffer_prepend0(Buffer buf, const char data) { return buffer_prepend(buf, data, strlen(data) + (buf->len == 0)); } Two function calls plus arithmetics plus step-return. Depending on the debugger interface(eclipse with gdb, vs, etc), one will have to press some form of Step 1 to 4 times to advance the line. Depending on the complier that was supposed to provide correct debug info (GCC vs msvcc vs xlc) and bugs, these steps may or may not work. It is short, but when you do multi platform code, a real pain to deal with. Consider aix and Linux multiplatform code for one of my past projects. My choice would have been: 1. Step and maybe hit a bug, msg the complier team, proceed writing register values on paper. 2. Break up the line, recompile. Few minutes on Linux, over half an hour on aix.
  - akkartik 10y ago
    Ok, I understand now. Thanks. This is a pretty common way to write C, though, it's not something specific to this particular codebase. You just had a non-standard use case where you were constantly running into low-level bugs. (In an embedded platform?) If you aren't in that domain anymore, it's worth revisiting the trade-off. In most domains, gdb's continue command is super useful.
    - quickben 10y ago
      Mhm. One was an actuall driver/firmware developmwnt. The other one a cross platform debugger. I will in few hours, thanks.
    - dboreham 10y ago
      No. Parent is correct. Writing code just to show how clever you are, at the expense of others who need to debug and understand it later, is poor taste.
      - abecedarius 10y ago
        It's pretty weird to see "correct" justified by calling the opposite "poor taste". We're talking about a mismatch between a style of code and certain tools; a better answer is to use tools that work well with the style of code you like.
        mypalmike 10y ago
        It's not just tooling. The more complex the expression, the more likely it would aid in understanding if you gave it a name.
        abecedarius 10y ago
        I agree that naming expressions often helps understanding, and that's worthwhile -- I guess I just disagree about this code at first glance. Maybe if I tried to delve into it.
  - oneeyedpigeon 10y ago
    How would you rewrite it? Would you use a local variable for the result from strlen(), for example?
    - quickben 10y ago
      Basically. The compiler will optimize it anyways in the end.

akkartik 10y ago

Fair enough. But where do you see multistatement lines in the link?

quickben 10y ago
For example: https://github.com/martanne/vis/blob/master/buffer.c https://github.com/martanne/vis/blob/master/buffer.c bool buffer_prepend0(Buffer buf, const char data) { return buffer_prepend(buf, data, strlen(data) + (buf->len == 0)); } Two function calls plus arithmetics plus step-return. Depending on the debugger interface(eclipse with gdb, vs, etc), one will have to press some form of Step 1 to 4 times to advance the line. Depending on the complier that was supposed to provide correct debug info (GCC vs msvcc vs xlc) and bugs, these steps may or may not work. It is short, but when you do multi platform code, a real pain to deal with. Consider aix and Linux multiplatform code for one of my past projects. My choice would have been: 1. Step and maybe hit a bug, msg the complier team, proceed writing register values on paper. 2. Break up the line, recompile. Few minutes on Linux, over half an hour on aix.
- akkartik 10y ago
  Ok, I understand now. Thanks. This is a pretty common way to write C, though, it's not something specific to this particular codebase. You just had a non-standard use case where you were constantly running into low-level bugs. (In an embedded platform?) If you aren't in that domain anymore, it's worth revisiting the trade-off. In most domains, gdb's continue command is super useful.
  - quickben 10y ago
    Mhm. One was an actuall driver/firmware developmwnt. The other one a cross platform debugger. I will in few hours, thanks.
  - dboreham 10y ago
    No. Parent is correct. Writing code just to show how clever you are, at the expense of others who need to debug and understand it later, is poor taste.
    - abecedarius 10y ago
      It's pretty weird to see "correct" justified by calling the opposite "poor taste". We're talking about a mismatch between a style of code and certain tools; a better answer is to use tools that work well with the style of code you like.
      - mypalmike 10y ago
        It's not just tooling. The more complex the expression, the more likely it would aid in understanding if you gave it a name.
        abecedarius 10y ago
        I agree that naming expressions often helps understanding, and that's worthwhile -- I guess I just disagree about this code at first glance. Maybe if I tried to delve into it.
- oneeyedpigeon 10y ago
  How would you rewrite it? Would you use a local variable for the result from strlen(), for example?
  - quickben 10y ago
    Basically. The compiler will optimize it anyways in the end.