«

In message <ie7r3n$ci7$>, James Kuyper
<> writes
>On 12/13/2010 08:11 AM, Chris H wrote:
>> In message<d6cbdc1c-e024-432d-aff6-
>> s.com>, Malcolm McLean<> writes
>...
>>> Adding printfs() will let
>>> you do this. If the program is incorrect it's not possible that adding
>>> a printf() will make it correct - it might go wrong in a different
>>> way, but the bug will still be there.
>>
>>
>> SO what help has that given? yo9u have added a whole load of variable
>> and got a different behaviour.
>
>Well, if you insert the printf() randomly, no help at all. A little bit
>of intelligence is assumed. A useful debugging printf() tells you, at a
>minimum, that the execution path through the code actually reached the
>printf() statement.


It does NOT tell you how it got there,

>It can also tell you the current value of one or more variables at the
>point where that statement is executed - that can be pretty useful
>information, if you choose which variables to print out properly.

It tells you the value of the variables in the printf but not what they
were before they got there nor where they came from

>My programs normally run on SGI Irix and Intel Linux platforms. For
>debugging, I can only use dbx to debug MIPSpro C programs on our Irix
>systems. I can use gdb to debug gcc programs on all of our our systems,
>but I try to avoid doing so, if I can, for the reasons given below.

Try a LauterBach or iSystems ICE.


>>> Actually, if the behaviour changes when you add a printf(), that's
>>> important and useful information. It tells you what sort of problem
>>> you are probably looking at.
>>
>> Which is? change in timing? memory usage? library usage? compilation?
>> reordering of variable and storage? change of optimisation? The lsit
>> goes on.
>
>In a real-time programming context, all of those are legitimate issues
>to worry about; though running the program inside a debugger has to be
>at least as disruptive as inserting printf() statements, so I'm not
>sure how that counts as an argument in favor of debuggers as compared
>to debugging printf().

Then you don't understand debuggers... then again if GDB is all you are
used to I am not surprised.

>However, not all programming is real-time programming. Most of my
>programs run in batch mode.

So for a few programs like your printf maybe OK...


>If inserting a debugging printf() into one of my programs caused a
>change to the non-debug outputs of the program for ANY of the reasons
>you listed above, that would unambiguously prove that something was
>defective. It could be my code, or one of the libraries my code is
>linked to, or the compiler, or the linker

Yes. And adding more code would change all of them so Heisenberg
applies.

>- but none of the issues you raised should affect the non-debug outputs
>if all of those components are working correctly.

Wrong if you add a printf. You have changed the code compiled. You
have changed what is linked so you are running a different program.


>> Without using a debugger with trace you have absolutely no idea how the
>> printf got the output it is giving.
>
>It's not uncommon for the problems that I'm investigating to be due to
>the fact that there's a mistake in the code that gives the entire
>program undefined behavior. Therefore, in principle, I can have no idea
>whatsoever why it produced any particular result - but the same
>principle applies to debugger output.

Nope not if you are using an ICE and I have used some debuggers that are
completely guaranteed to be 100% identical to the hardware.

>In practice, almost all

So most but not all....

> printf() expressions that are evaluated prior to the execution of the
>defective code have precisely the behavior I would expect them to have,
>as do most

Again most but not all....

> of the printf() statements that evaluated afterwards, so long as
Again another caveat.

> the program continues to run. If I don't know "how the printf got the
>output it is giving",

You don't you are assuming that the code behaved exactly as you expected
and put the correct variable into the printf and what as in that memory
location was the correct variable. Without a debugger you are haqve no
idea.

>that's a sign of a very serious problem of some kind - it's not at all
>the normal case.

Yes it is a common case and the fact that you have not realised that it
does happen is the problem you don't know what you don't know.

SO you are saying printf seems to work in a limited number of cases but
you don't really know how or why.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <>, pete <>
writes
>Malcolm McLean wrote:
>
>> I've never had a case of a known bug which couldn't be tracked down by
>> diagnostic alterations to the source code, but which was solved by use
>> of a debugger. I've had the reverse.
>
>The requirement for the word "known" to be in that sentence,
>is one of the limitations of not using a debugger.
>
>Debuggers and customers are both capable of finding other bugs.

Unit testing for one.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Dec 14, 3:40*pm, Chris H <ch...@phaedsys.org> wrote:
> In message <ie7r3n$ci...@news.eternal-september.org>, James Kuyper
>
> >- but none of the issues you raised should affect the non-debug outputs
> >if all of those components are working correctly.
>
> Wrong if you add a printf. *You have changed the code compiled. *You
> have changed what is linked so you are running a different program.
>
It's the difference between theory and reality.

In theory there could be a bug in the call to printf() itself. In
theory adding the printf could change the program, unmasking a second
bug that cancels out the first, and creating a very puzzling
situation.
In practice this doesn't happen.

Also, you can't remove a bug by adding a printf. You can mask it, but
if that happens the first thing you do is comment out the diagnostic
to see if the bug reappears. If not, something was funny with the
original bug report - so that tells you where to focus your efforts.
If the bug does reappear, we can now toggle between "bug masked" and
"bug visible" at will, and we've got a more powerful debugging
instrument than any debugger.

Chris H <> writes:
> In message <ie7r3n$ci7$>, James Kuyper
> <> writes
[...]
>>In practice, almost all
>
> So most but not all....
>
>> printf() expressions that are evaluated prior to the execution of the
>>defective code have precisely the behavior I would expect them to have,
>>as do most
>
> Again most but not all....
>
>> of the printf() statements that evaluated afterwards, so long as
> Again another caveat.

Yes, there are caveats. He said so very clearly. Why do you keep
repeating the point he's already made?

>> the program continues to run. If I don't know "how the printf got the
>>output it is giving",
>
> You don't you are assuming that the code behaved exactly as you expected
> and put the correct variable into the printf and what as in that memory
> location was the correct variable. Without a debugger you are haqve no
> idea.
>
>>that's a sign of a very serious problem of some kind - it's not at all
>>the normal case.
>
> Yes it is a common case and the fact that you have not realised that it
> does happen is the problem you don't know what you don't know.
>
> SO you are saying printf seems to work in a limited number of cases but
> you don't really know how or why.

No, he's saying that printf *does* work in the vast majority of
cases for the code that he works on. What you are asserting is "a
common case" (adding printfs drastically changing the behavior of
the program) is not a common case *for him*. It may well be a common
case for you, but not everyone works in the same environment you do.

Please pay attention, and show some respect for the fact that other
people's experiences might be valid even if they don't match yours.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 12/14/2010 08:40 AM, Chris H wrote:
> In message<ie7r3n$ci7$>, James Kuyper
> <> writes
....
>> of intelligence is assumed. A useful debugging printf() tells you, at a
>> minimum, that the execution path through the code actually reached the
>> printf() statement.
>
>
> It does NOT tell you how it got there,

Neither does any debugger I'm familiar with. If I need to know how it
got there, I need to insert debugging printf()s along the possible paths
to that location, so I can trace the path actually used. I'll readily
grant you that the debugger is a much more convenient way to obtain the
same information - except when no usable debugger is available, which is
the only context in which I'd fall back on debugging printf()s.

>> It can also tell you the current value of one or more variables at the
>> point where that statement is executed - that can be pretty useful
>> information, if you choose which variables to print out properly.
>
> It tells you the value of the variables in the printf but not what they
> were before they got there nor where they came from

Neither does any debugger I've ever used. When I type "print
total_price", in the debugger, it doesn't tell me any more information
(or any less) than I get from fprintf(stderr, "%g", total_price).

>> My programs normally run on SGI Irix and Intel Linux platforms. For
>> debugging, I can only use dbx to debug MIPSpro C programs on our Irix
>> systems. I can use gdb to debug gcc programs on all of our our systems,
>> but I try to avoid doing so, if I can, for the reasons given below.
>
> Try a LauterBach or iSystems ICE.

I'll look into those; I know nothing about them, and I have no idea
whether they're installed on our systems. If they cost money, it will
probably be difficult to get authorization to install them.

>> - but none of the issues you raised should affect the non-debug outputs
>> if all of those components are working correctly.
>
> Wrong if you add a printf. You have changed the code compiled. You
> have changed what is linked so you are running a different program.

True - but if the new program produces different non-debug outputs than
the original, then the original was defective, either in it's source
code, compilation, or linkage. Furthermore, the way in which the
non-debug outputs differ provides clues (not necessarily useful ones,
unfortunately) about the nature of the defect.

>> In practice, almost all
>
> So most but not all....

"most" is sufficient to justify the practice.

>> printf() expressions that are evaluated prior to the execution of the
>> defective code have precisely the behavior I would expect them to have,
>> as do most
>
> Again most but not all....

Yes, and again, "most" is sufficient.

>> of the printf() statements that evaluated afterwards, so long as
> Again another caveat.
>
>> the program continues to run. If I don't know "how the printf got the
>> output it is giving",
>
> You don't you are assuming that the code behaved exactly as you expected

Actually, no, The fact that there's a bug to be investigated guarantees
that something unexpected is happening - if what I know about the
program means that the behavior was not unexpected, then the
investigation is already complete. The purpose of the debugging printf()
is to identify places where the code does NOT behave as I expect it to.

> and put the correct variable into the printf ...

fprintf(stderr, "%s", wrong_variable) produces the same result as
issuing the debugger command "print wrong_variable" - how does that
issue favor debuggers over debugging printf()s?

> ... and what as in that memory
> location was the correct variable. ...

Ensuring the correctness of the memory location when my debugging printf
refers to a variable by name is the compiler's responsibility, not mine.
If it collects the information from the wrong memory location when I
wrote the right variable name, it's a compiler bug, not a defect with my
printf(). In 45 years of programming, I've only identified a few
compiler bugs, and I've never identified one that involved anything as
fundamental as messing up the symbol table.

However, if I should be worried about the possibility that
fprintf(stderr, "%d", right_variable_name) will actually print out the
value stored in some different piece of memory, then it seems to me that
I should be equally worried about the possibility that it will generate
a symbol table for the debugger that identifies the wrong memory
location for right_variable_name.

> ... Without a debugger you are haqve no
> idea.

You're making precisely the same correctness assumptions about the
commands you type into the debugger, and face precisely the same kind of
risks if those assumptions are incorrect.

>> that's a sign of a very serious problem of some kind - it's not at all
>> the normal case.
>
> Yes it is a common case and the fact that you have not realised that it
> does happen is the problem you don't know what you don't know.

Well, you've yet to explain what it is that you think I don't know. As
far as I can see, you're worried about mysterious unexplained "unknowns"
that seem far more relevant to real-time programming than to the kind of
batch-processing environment I'm working in. Not everyone works in the
same kind of environment as you do, and generalizations that fail to
take that fact into consideration are can fail when applied outside that
domain.

> SO you are saying printf seems to work in a limited number of cases but
> you don't really know how or why.

This "limited number of cases" covers virtually every line of code I've
written in the past 14 years (I've done real-time programming before,
just not recently), and most of the code I wrote in the two decades
before then. I know precisely why I think it works; if you think I'm
wrong about why it works, you should explain in more detail what it is
you think I'm unaware of.

On 2010-12-14, Kenneth Brody <> wrote:
> Remember, both "diagnostic alterations to the source code" as well as
> running in a debugger can change the state of the machine at the time the
> bug is hit. And, especially in the case of UB, such a change can
> drastically alter the symptoms.

Yes. Had a bug once which occurred only if you weren't running in the
debugger. Didn't have to *do* anything in the debugger; the mere fact of
running under the debugger changed it. (Pretty sure it was a compiler
bug to do with caching, but I will never know.)

I like diagnostics as a tool because they allow me to go back and forth
and look at things, and find out the answers to questions I might not have
thought to ask at the right time. I often debug pseudo problems just by
looking at the logs submitted.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

In message <>, Keith Thompson <kst-
> writes
>Chris H <> writes:
>> In message <ie7r3n$ci7$>, James Kuyper
>> <> writes
>[...]
>>>In practice, almost all
>>
>> So most but not all....
>>
>>> printf() expressions that are evaluated prior to the execution of the
>>>defective code have precisely the behavior I would expect them to have,
>>>as do most
>>
>> Again most but not all....
>>
>>> of the printf() statements that evaluated afterwards, so long as
>> Again another caveat.
>
>Yes, there are caveats. He said so very clearly. Why do you keep
>repeating the point he's already made?
>
>>> the program continues to run. If I don't know "how the printf got the
>>>output it is giving",
>>
>> You don't you are assuming that the code behaved exactly as you expected
>> and put the correct variable into the printf and what as in that memory
>> location was the correct variable. Without a debugger you are haqve no
>> idea.
>>
>>>that's a sign of a very serious problem of some kind - it's not at all
>>>the normal case.
>>
>> Yes it is a common case and the fact that you have not realised that it
>> does happen is the problem you don't know what you don't know.
>>
>> SO you are saying printf seems to work in a limited number of cases but
>> you don't really know how or why.
>
>No, he's saying that printf *does* work in the vast majority of
>cases for the code that he works on. What you are asserting is "a
>common case" (adding printfs drastically changing the behavior of
>the program) is not a common case *for him*. It may well be a common
>case for you, but not everyone works in the same environment you do.


I agree... however what he finds useful in some cases does not work in
the wider field. In SOME areas printf may be useful in many other sit
is not and or counter productive.

>Please pay attention, and show some respect for the fact that other
>people's experiences might be valid even if they don't match yours.

Exactly. What works in a few cases may not work generally. He should
realise that.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <ie85af$enn$>, James Kuyper
<> writes
>On 12/14/2010 08:40 AM, Chris H wrote:
>> In message<ie7r3n$ci7$>, James Kuyper
>> <> writes
>...
>>> of intelligence is assumed. A useful debugging printf() tells you, at a
>>> minimum, that the execution path through the code actually reached the
>>> printf() statement.
>>
>>
>> It does NOT tell you how it got there,
>
>Neither does any debugger I'm familiar with.

Then you have a limited experience.

>> Try a LauterBach or iSystems ICE.
>
>I'll look into those; I know nothing about them, and I have no idea
>whether they're installed on our systems. If they cost money, it will
>probably be difficult to get authorization to install them.

They are the worlds two leading Emulator systems.

>> ... Without a debugger you are haqve no
>> idea.
>
>You're making precisely the same correctness assumptions about the
>commands you type into the debugger, and face precisely the same kind
>of risks if those assumptions are incorrect.

Not correct.

>This "limited number of cases" covers virtually every line of code I've
>written in the past 14 years (I've done real-time programming before,
>just not recently), and most of the code I wrote in the two decades
>before then. I know precisely why I think it works; if you think I'm
>wrong about why it works, you should explain in more detail what it is
>you think I'm unaware of.


And you have not come across Lauterbach or iSystem?....


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Dec 15, 11:30*am, Richard <rgrd...@gmail.com> wrote:
>
> Using printf shows someone to be clueless in the vast majority of cases.
>
> You're being an imbecile to support such practices.
>
The printf() users have given perfectly good reasons to support their
practices.

Now I'm not a militant anti-debugger person, I have used them, I might
be persuaded to uses them as a general practice again.

If everyone who disagrees with you on debugging is an imbecile, it's
fair to guess that everyone who disagrees with you on any subject
whatsoever is an imbecile.

On Dec 15, 11:18*am, Chris H <ch...@phaedsys.org> wrote:
> In message <ie85af$en...@news.eternal-september.org>, James Kuyper
> <jameskuy...@verizon.net> writes
>
> >Neither does any debugger I'm familiar with.
>
> Then you have a limited experience.
>
There are hundreds of hardware platforms out there, many with
different debuggers from different companies. It's unlikely that any
one programmer would have extensive experience of more than one or two
domains. You yourself obviously have limited experience of parallel
systems, where debuggers face challenges.

Instead of making these supercilious comments, how about simply and
humbly adding your experience, which may differ from that of other
members of the newsgroup?