5 ms·

> I'm amazed and a bit saddened whenever I hear sentiments like this. These days more than ever. The big advantage of printf as a debug technique is that it do

by anamax 16y ago

> I'm amazed and a bit saddened whenever I hear sentiments like this. These days more than ever. The big advantage of printf as a debug technique is that it doesn't work unless you understand what you're doing. If you plan to debug using printf, you must write code that is easy to understand. Great debuggers let you try to fix code that you don't understand. Worse yet, they make it reasonable to write such code. Since the person reading the code is never as smart as the person who wrote the code, encouraging simple to understand code is extremely important.

Roboprog 16y ago
A big disadvantage of printf() in C (or similar non-memory-managed languages) is that printing values can disturb the "noise" on the stack that you were trying to find. That is, if you had a bug due to an uninitialized local variable or buffer overrun, the printf() call could "stabilize" things and cause a bug to stop manifesting. Better to use a debugger, if you can. Not that I haven't ever sprinkled print's into the middle of a big mass of somebody else's code or framework just to get the initial lay of the land :-)
- vicaya 16y ago
  uh, the -g compiler flag to enable debugging will create much more disturbance than a few printf ever could, debuggers are mostly useless for tracking down race conditions as they change the timing completely. OTOH, I'd use a low overhead logging package instead of printfs.
  - Roboprog 16y ago
    Good one: yes, race conditions are not going to manifest while manually slowly stepping. You of course need to plan / read carefully for code which will be vulnerable to such. Regarding "-g", at the job a few years ago where we were using C for some in-house jobs, we skipped using "-O" for the most part and simply deployed with "-g" left on. Better safe than sorry for single-use software.
vilya 16y ago
I disagree with almost every sentence in your post, but there's one bit in particular I wanted to focus on: > The big advantage of printf as a debug technique is that it doesn't work unless you understand what you're doing. This isn't true, nor would it be an advantage if it were. Any fool can stick a printf statement into their code, just like any fool can run it in a debugger. You might get lucky and find the problem, or you might not. Understanding what you're doing will help you out whichever technique you use. Better yet, it will help you decide which technique is more appropriate to the problem.
- anamax 16y ago
  > Any fool can stick a printf statement into their code, just like any fool can run it in a debugger. You might get lucky and find the problem That's like saying that you might get lucky if you make random changes to program code. Yes, it's true, but .... > Understanding what you're doing will help you out whichever technique you use. Better yet, it will help you decide which technique is more appropriate to the problem. Except that I was talking about understanding the program, not "what you're doing". In my experience, debuggers let me find things, or, more often, think that I'm doing something useful, with less understanding than printf. YMMV.

by anamax 16y ago

Roboprog 16y ago

A big disadvantage of printf() in C (or similar non-memory-managed languages) is that printing values can disturb the "noise" on the stack that you were trying to find. That is, if you had a bug due to an uninitialized local variable or buffer overrun, the printf() call could "stabilize" things and cause a bug to stop manifesting. Better to use a debugger, if you can. Not that I haven't ever sprinkled print's into the middle of a big mass of somebody else's code or framework just to get the initial lay of the land :-)

vicaya 16y ago
uh, the -g compiler flag to enable debugging will create much more disturbance than a few printf ever could, debuggers are mostly useless for tracking down race conditions as they change the timing completely. OTOH, I'd use a low overhead logging package instead of printfs.
- Roboprog 16y ago
  Good one: yes, race conditions are not going to manifest while manually slowly stepping. You of course need to plan / read carefully for code which will be vulnerable to such. Regarding "-g", at the job a few years ago where we were using C for some in-house jobs, we skipped using "-O" for the most part and simply deployed with "-g" left on. Better safe than sorry for single-use software.

vilya 16y ago

I disagree with almost every sentence in your post, but there's one bit in particular I wanted to focus on: > The big advantage of printf as a debug technique is that it doesn't work unless you understand what you're doing. This isn't true, nor would it be an advantage if it were. Any fool can stick a printf statement into their code, just like any fool can run it in a debugger. You might get lucky and find the problem, or you might not. Understanding what you're doing will help you out whichever technique you use. Better yet, it will help you decide which technique is more appropriate to the problem.

anamax 16y ago
> Any fool can stick a printf statement into their code, just like any fool can run it in a debugger. You might get lucky and find the problem That's like saying that you might get lucky if you make random changes to program code. Yes, it's true, but .... > Understanding what you're doing will help you out whichever technique you use. Better yet, it will help you decide which technique is more appropriate to the problem. Except that I was talking about understanding the program, not "what you're doing". In my experience, debuggers let me find things, or, more often, think that I'm doing something useful, with less understanding than printf. YMMV.