«

We know from my last installments, that there are some people here that
go around telling "there is no stack in C", because the word "stack"
doesn't appear in the C standard.

Apparently, more or less the same people, start telling that
it is enough to read the code to be able to debug a program,
without using such low level tools like a debugger.

Having written a debugger, and passed countless hours of my professional
life using those tools (gdb, dbx, msvc, and many others) I am
suprised that people like Mr Bos can say in this forum
that it is sufficient to READ the code to be able to debug it.

In that debugger thread, I wrote:

> "It is impossible for any human to DEBUG a program written by others
> without a debugger, of course if the program has a certain size
> (bigger than, say, 1500 -2000 lines)"

This was translated by Mr Bos into:

" its author is (by his own admission, in
that other thread) incapable of READING code beyond 2000 lines"

I complained that this was a LIE, i.e. a complete misrepresentation of
what I said.

Mr Heathfield and Mr Bos answered, (in substance) that since I could not
debug a program of more than 1500-2000 lines without a debugger I am
unavle to read it, since if I would be able to read it I would spot
the bug immediately.

Now, question for the people that keep a small part of common sense
here:

Is *reading* a program the *same* as *DEBUGGING* a program?

Are serious people here willing to believe this stories of people
debugging huge code bases without a debugger?

I stay by my position:

A code base bigger than 1500 lines is no longer debuggable in an
abstract sense just by reading code. It needs a debugger.

Note that we suppose a real-time, event-driven code execution,
where you can have faulty libraries, faulty interrupts servicing
programs, etc. ANYTHING.



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia schrieb:

> Now, question for the people that keep a small part of common sense
> here:
>
> Is *reading* a program the *same* as *DEBUGGING* a program?

No it isn't.

> Are serious people here willing to believe this stories of people
> debugging huge code bases without a debugger?

I am not. While I disagree on some points with your opinion (especially
concerning OS specifics) I have to say I absolutely second your opinion
on this one.

> I stay by my position:
>
> A code base bigger than 1500 lines is no longer debuggable in an
> abstract sense just by reading code. It needs a debugger.

Absolutely. Sometimes the code might even be shorter, but more
complicated. I've seen race conditions in embedded systems in code which
way even *way* shorter (say 300-500 lines) which were just plain
impossible to find without a good hardware debugger (like a Lauterbach).

Regards,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$>

jacob navia <> writes:
<snip>
> Having written a debugger, and passed countless hours of my professional
> life using those tools (gdb, dbx, msvc, and many others) I am
> suprised that people like Mr Bos can say in this forum
> that it is sufficient to READ the code to be able to debug it.

It is obviously sufficient in that people have done so for decades.
There can be a lively argument about whether is it desirable, optimal,
the right way for everyone and so on, but it is undeniably possible.

> In that debugger thread, I wrote:
>
>> "It is impossible for any human to DEBUG a program written by others
>> without a debugger, of course if the program has a certain size
>> (bigger than, say, 1500 -2000 lines)"

I did that for living. In the days of punched cards there were no
debuggers (at least not for the likes of me) and inserting print
statements was way too slow. My job was to find the bugs in other
people's programs. Some were several thousand "lines" long.

It is possible and I can't see how you can think it is not.

<snip>
> Now, question for the people that keep a small part of common sense
> here:
>
> Is *reading* a program the *same* as *DEBUGGING* a program?

Only of the end result is the elimination of an error (i.e a bug).
Some writing (or punching) is obviously required as well.

> Are serious people here willing to believe this stories of people
> debugging huge code bases without a debugger?

Honestly, how can you doubt it? You must know that bugs existed
before debuggers and people were, on occasion, able to remove them.

--
Ben.

jacob navia wrote:

> We know from my last installments, that there are some people here
> that go around telling "there is no stack in C", because the word
> "stack" doesn't appear in the C standard.
>
> Apparently, more or less the same people, start telling that
> it is enough to read the code to be able to debug a program,
> without using such low level tools like a debugger.
>
> Having written a debugger, and passed countless hours of my
> professional life using those tools (gdb, dbx, msvc, and many others)
> I am suprised that people like Mr Bos can say in this forum
> that it is sufficient to READ the code to be able to debug it.
>
> In that debugger thread, I wrote:
>
> > "It is impossible for any human to DEBUG a program written by
> > others without a debugger, of course if the program has a certain
> > size (bigger than, say, 1500 -2000 lines)"
>
> This was translated by Mr Bos into:
>
> " its author is (by his own admission, in
> that other thread) incapable of READING code beyond 2000 lines"
>
> I complained that this was a LIE, i.e. a complete misrepresentation of
> what I said.
>
> Mr Heathfield and Mr Bos answered, (in substance) that since I could
> not debug a program of more than 1500-2000 lines without a debugger I
> am unavle to read it, since if I would be able to read it I would spot
> the bug immediately.
>
> Now, question for the people that keep a small part of common sense
> here:
>
> Is *reading* a program the *same* as *DEBUGGING* a program?

For some small set of programs it *could* be enough to debug it by
reading it's source.

> Are serious people here willing to believe this stories of people
> debugging huge code bases without a debugger?
>
> I stay by my position:
>
> A code base bigger than 1500 lines is no longer debuggable in an
> abstract sense just by reading code. It needs a debugger.

I would consider the code's complexity and it's interaction with outside
environment rather than merely it's LoC count. A data compression
program for example has a fairly simple I/O logic and it usually not
event driven, so it may be possible to debug it by reading the source
code, even if it were more than a few thousand lines.

Remember, well placed assert and printf can pinpoint out the function
which failed, so you don't always have to read the entire program's
source to debug a failing function.

It depends very much on the nature of the bug. A typo in rather easy to
catch. Something like a buffer overflow is quite a bit harder, without
appropriate tools, particularly if the effects of the overflow are
insidious.

> Note that we suppose a real-time, event-driven code execution,
> where you can have faulty libraries, faulty interrupts servicing
> programs, etc. ANYTHING.

Ah OK. A runtime debugger would be very useful I admit. That's not to
say that specific bugs in specific programs can't also be caught by
other methods.

A combination of assert, printf, unit testing, desk checking and runtime
debugging with a debugger and memory bounds checker ought to catch most
bugs. Use whatever works for the program in hand, IMO.

Ben Bacarisse <> writes:

> jacob navia <> writes:
> <snip>
>> Having written a debugger, and passed countless hours of my professional
>> life using those tools (gdb, dbx, msvc, and many others) I am
>> suprised that people like Mr Bos can say in this forum
>> that it is sufficient to READ the code to be able to debug it.
>
> It is obviously sufficient in that people have done so for decades.
> There can be a lively argument about whether is it desirable, optimal,
> the right way for everyone and so on, but it is undeniably possible.

Swimming the Atlantic is possible. I prefer to fly.

>
>> In that debugger thread, I wrote:
>>
>>> "It is impossible for any human to DEBUG a program written by others
>>> without a debugger, of course if the program has a certain size
>>> (bigger than, say, 1500 -2000 lines)"
>
> I did that for living. In the days of punched cards there were no
> debuggers (at least not for the likes of me) and inserting print
> statements was way too slow. My job was to find the bugs in other
> people's programs. Some were several thousand "lines" long.

Yawn. Debuggers DO exist now. I started with assembler and no
debugger. So what? We are talking C NOW.

>
> It is possible and I can't see how you can think it is not.

Oh for goodness sake. It is "possible" to do anything. But why bother to
spend weeks finding that in one case its NOT possible? Use the damn
debugger for crying out loud.

>
> <snip>
>> Now, question for the people that keep a small part of common sense
>> here:
>>
>> Is *reading* a program the *same* as *DEBUGGING* a program?
>
> Only of the end result is the elimination of an error (i.e a bug).
> Some writing (or punching) is obviously required as well.
>
>> Are serious people here willing to believe this stories of people
>> debugging huge code bases without a debugger?
>
> Honestly, how can you doubt it? You must know that bugs existed
> before debuggers and people were, on occasion, able to remove them.

Arrrghhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!

For the record:

Yes, people CAN find SOME bugs without a debugger.

But WHY would one bother in 99.999% of the times when a debugger is
available.

What is it with CLC and mindless word games all the time? It's surreal.

santosh <> writes:

> jacob navia wrote:
>
>> We know from my last installments, that there are some people here
>> that go around telling "there is no stack in C", because the word
>> "stack" doesn't appear in the C standard.
>>
>> Apparently, more or less the same people, start telling that
>> it is enough to read the code to be able to debug a program,
>> without using such low level tools like a debugger.
>>
>> Having written a debugger, and passed countless hours of my
>> professional life using those tools (gdb, dbx, msvc, and many others)
>> I am suprised that people like Mr Bos can say in this forum
>> that it is sufficient to READ the code to be able to debug it.
>>
>> In that debugger thread, I wrote:
>>
>> > "It is impossible for any human to DEBUG a program written by
>> > others without a debugger, of course if the program has a certain
>> > size (bigger than, say, 1500 -2000 lines)"
>>
>> This was translated by Mr Bos into:
>>
>> " its author is (by his own admission, in
>> that other thread) incapable of READING code beyond 2000 lines"
>>
>> I complained that this was a LIE, i.e. a complete misrepresentation of
>> what I said.
>>
>> Mr Heathfield and Mr Bos answered, (in substance) that since I could
>> not debug a program of more than 1500-2000 lines without a debugger I
>> am unavle to read it, since if I would be able to read it I would spot
>> the bug immediately.
>>
>> Now, question for the people that keep a small part of common sense
>> here:
>>
>> Is *reading* a program the *same* as *DEBUGGING* a program?
>
> For some small set of programs it *could* be enough to debug it by
> reading it's source.

You miss the point. Yes one CAN "debug" when reading but reading is NOT
the same as active debugging.

>
>> Are serious people here willing to believe this stories of people
>> debugging huge code bases without a debugger?
>>
>> I stay by my position:
>>
>> A code base bigger than 1500 lines is no longer debuggable in an
>> abstract sense just by reading code. It needs a debugger.
>
> I would consider the code's complexity and it's interaction with outside
> environment rather than merely it's LoC count. A data compression
> program for example has a fairly simple I/O logic and it usually not
> event driven, so it may be possible to debug it by reading the source
> code, even if it were more than a few thousand lines.
>
> Remember, well placed assert and printf can pinpoint out the function
> which failed, so you don't always have to read the entire program's
> source to debug a failing function.
>
> It depends very much on the nature of the bug. A typo in rather easy to
> catch. Something like a buffer overflow is quite a bit harder, without
> appropriate tools, particularly if the effects of the overflow are
> insidious.
>
>> Note that we suppose a real-time, event-driven code execution,
>> where you can have faulty libraries, faulty interrupts servicing
>> programs, etc. ANYTHING.
>
> Ah OK. A runtime debugger would be very useful I admit. That's not to

What do you mean, a runtime debugger? Do you use debuggers?

> say that specific bugs in specific programs can't also be caught by
> other methods.

No one has said anything different.

>
> A combination of assert, printf, unit testing, desk checking and runtime
> debugging with a debugger and memory bounds checker ought to catch most
> bugs. Use whatever works for the program in hand, IMO.

printf is amateurish and frowned upon. Asserts litter the code
unnecessarily IMO but have their uses.

Remember : the removal or addition in any module of ONE printf could
trigger and entire QA phase.

use a debugger and no changes to the code are required bar compile with
debug info on. Then the bug is found and ONE module is then (generally)
updated to make that fix.

jacob navia wrote:

> I stay by my position:
>
> A code base bigger than 1500 lines is no longer debuggable in an
> abstract sense just by reading code. It needs a debugger.

If you've dropped your "by multiple people" clause, and by "debugger"
you mean what I read most other people as meaning -- something like
gdb, rather than something like fprintf statements -- then your first
sentence may be true, but your second sentence isn't.

(fx:grope)

My Cayenne compiler & linker appear to be roughly 9000 lines (of Cayenne).
[Hmm. OK, there are misleading Web hits for Cayenne; this isn't any of
them. My Cayenne is a Pop11 derivative; Algolish syntax, Lispy datatypes,
open stack for multiple values.]

My Spice-and-ECMAScript compiler/interpreter appears to be roughly 20000
lines of C. [Spice is another Pop11-inspired language, not the circuit
simulator thingy.]

[Neither of these is public; sorry.]

I believe the most I've used a debugger for on those was to get a backtrace
after a coredump.

Note VERY CAREFULLY that I am NOT claiming that either of these is bug-free,
nor am I claiming that using a debugger on either of them would have been
pointless. I'm saying that they WERE developed with such minimal use of
debuggers. Nor were the bugs that manifested particularly hard to find.
The compiler/interpreter did have controllable logging code, which I
wouldn't count as "a debugger" but Jacob might. These were from my pre-TDD
days, so I didn't even have unit tests to comfort me, but I did have
a testbase of sorts.

--
"Well begun is half done." - Proverb

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

jacob navia wrote:
> We know from my last installments, that there are some people here
> that go around telling "there is no stack in C", because the word
> "stack" doesn't appear in the C standard.
>
> Apparently, more or less the same people, start telling that
> it is enough to read the code to be able to debug a program,
> without using such low level tools like a debugger.
>
> Having written a debugger, and passed countless hours of my
> professional life using those tools (gdb, dbx, msvc, and many others)
> I am suprised that people like Mr Bos can say in this forum
> that it is sufficient to READ the code to be able to debug it.
>
> In that debugger thread, I wrote:
>
>> "It is impossible for any human to DEBUG a program written by others
>> without a debugger, of course if the program has a certain size
>> (bigger than, say, 1500 -2000 lines)"
>
> This was translated by Mr Bos into:
>
> " its author is (by his own admission, in
> that other thread) incapable of READING code beyond 2000 lines"
>
> I complained that this was a LIE, i.e. a complete misrepresentation of
> what I said.
a lie is very different from a misinterpretatation.

> Mr Heathfield and Mr Bos answered, (in substance) that since I could
> not debug a program of more than 1500-2000 lines without a debugger I
> am unavle to read it, since if I would be able to read it I would spot
> the bug immediately.
And in response you called one a liar and the other a moron, which is just
inacceptable behavoir.

> Now, question for the people that keep a small part of common sense
> here:
>
> Is *reading* a program the *same* as *DEBUGGING* a program?
reading and understanding the code will enable to debug the code.
You need to write/modify the code to debug it, i.e. to remove the bug.
Without reading and understanding the code it won't be possible to find any
bug.

Using a debugger won't debug code (so calling it debugger is a misnomer, the
only real debugger is the editor), at best it'll show where the bug is,
provided (once again) that you read and understand the code.
A debugger may be a great help in finding the bug. On the other hand
sometimes it even hinders finding it.

> Are serious people here willing to believe this stories of people
> debugging huge code bases without a debugger?
Yes. The ability (or lack thereof) to do this myself isn't relevant to that
believe.

I do know from 1st hand experience that is even possible without reading the
code (well, in this case that guy didn't need to read it it, he knew it,
because he wrote it)

> I stay by my position:
>
> A code base bigger than 1500 lines is no longer debuggable in an
> abstract sense just by reading code. It needs a debugger.
More importantly it needs a documentation, a description of the
architecture.
Lacking that you can only resort to read the code to reverse engineer that
description

> Note that we suppose a real-time, event-driven code execution,
> where you can have faulty libraries, faulty interrupts servicing
> programs, etc. ANYTHING.

Bye, Jojo

jacob navia said:

> We know from my last installments, that there are some people here that
> go around telling "there is no stack in C", because the word "stack"
> doesn't appear in the C standard.

To be more precise, the C Standard does not require implementations to use
a stack. If an implementor finds it easier or more robust or more
efficient to provide, say, function calls and auto objects and the like
using some other mechanism, he has the freedom to do that. It is not,
strictly speaking, necessary to understand stacks in order to understand
an ISO C program. That knowledge may or may not be helpful, but it is not
*necessary*. In fact, it can lead to *mis*understandings, as it can cause
people to confuse implementation details with standard C, and that's not a
good thing to do.

> Apparently, more or less the same people, start telling that
> it is enough to read the code to be able to debug a program,
> without using such low level tools like a debugger.

That's misleading. What some people have claimed is that *they* can debug
some proportion of programs (the proportion varies amongst the claimants)
without a debugger. I believe this, because I've done it myself. But
nobody here is claiming that using a debugger is somehow bad or wrong.
Everybody approaches debugging in their own way. Some people find a
debugger useful, and some do not, and some (like myself) find a debugger
useful *some* of the time - at the very least, for getting backtraces.


> Having written a debugger,

So have I - albeit a very little one.

> and passed countless hours of my professional
> life using those tools (gdb, dbx, msvc, and many others) I am
> suprised that people like Mr Bos can say in this forum
> that it is sufficient to READ the code to be able to debug it.

To debug the program, it is necessary to understand it (or at least that
part of it that is not behaving). To understand it, one must be able to
read it with comprehension. A debugger can be useful in aiding that
comprehension. Nevertheless, not everyone finds it desirable to use a
debugger in order to gain that comprehension. Some people work better with
debuggers, and some work better without them. "Whatever works" is what
matters.


> In that debugger thread, I wrote:
>
> > "It is impossible for any human to DEBUG a program written by others
> > without a debugger, of course if the program has a certain size
> > (bigger than, say, 1500 -2000 lines)"
>
> This was translated by Mr Bos into:
>
> " its author is (by his own admission, in
> that other thread) incapable of READING code beyond 2000 lines"
>
> I complained that this was a LIE, i.e. a complete misrepresentation of
> what I said.

This was all dealt with in that thread.

> Mr Heathfield and Mr Bos answered, (in substance) that since I could not
> debug a program of more than 1500-2000 lines without a debugger I am
> unavle to read it, since if I would be able to read it I would spot
> the bug immediately.

This was all dealt with in that thread. Note that you have mischaracterised
your opponents' position by using the word "immediately", and you have
mischaracterised *my* position by saying that I claimed you can't read
code. What I did was explain the reasoning that seemed to me to be
self-evident in Richard Bos's statement. I did not say that you can't read
code. It does seem, however, that you are unable to read (some) Usenet
articles, at least with any sensible level of comprehension.

I would be very surprised to encounter any experienced and competent C
programmer who has not debugged at least one program of greater than 2000
lines without recourse to a debugger, and yet that is what you claimed is
impossible. Presumably you mean that *you* find it impossible. You might
want to consider the possibility that not everybody experiences the same
limitations as you do in the same areas to precisely the same extent.
People are *different*, and some people have better debugging skills than
you. (Likewise, some people have better debugging skills than me.) To call
them liars just for speaking out from their experience is not a good way
to treat people.

> Now, question for the people that keep a small part of common sense
> here:
>
> Is *reading* a program the *same* as *DEBUGGING* a program?

To *understand* code is to debug it. If you can't read it, you can't
understand it, so you can't debug it. Reading code is a fundamental part
of being a programmer. Now, it may be that you find it easier to read code
in a debugger than in an editor - in which case, fine! Nothing wrong with
that! But just because you do, that doesn't mean that others do.

> Are serious people here willing to believe this stories of people
> debugging huge code bases without a debugger?

Yes.

>
> I stay by my position:
>
> A code base bigger than 1500 lines is no longer debuggable in an
> abstract sense just by reading code. It needs a debugger.

And I know that I /have/ debugged a code base bigger than that, without a
debugger. Therefore, I don't accept your claim, because I know from
personal experience that it isn't correct.


> Note that we suppose a real-time, event-driven code execution,
> where you can have faulty libraries, faulty interrupts servicing
> programs, etc. ANYTHING.

You did not say so in your original claim, so you are now back-pedalling
(which is good, because it shows that you realise your original claim was
wrong). Nevertheless, yes, I've debugged real-time event-driven programs
without using a debugger. Not to show off, not to prove it's possible, but
because it was the quickest way to get the job done. I have *also*
debugged similar programs *with* a debugger. For me, a debugger is *one*
tool in my toolkit, and not one that I use a great deal.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

jacob navia wrote:
> We know from my last installments, [... aggrieved rant snipped ...]
>
> Now, question for the people that keep a small part of common sense
> here:
>
> Is *reading* a program the *same* as *DEBUGGING* a program?

No, it is not the *same* (emphasis yours and mine alike).

> Are serious people here willing to believe this stories of people
> debugging huge code bases without a debugger?

Yes. Perhaps this defines me as "non-serious" in your
estimation, but my employers seem to disagree with you and
I'm not giving back forty years' worth of paychecks on your
say-so.

> I stay by my position:
>
> A code base bigger than 1500 lines is no longer debuggable in an
> abstract sense just by reading code. It needs a debugger.

No, that's folly. For some programs, even for some programs
shorter than 1500 lines, a debugger can be helpful. But for
most programs, even for some many times longer, interactive
debuggers are a waste of time.

> Note that we suppose a real-time, event-driven code execution,
> where you can have faulty libraries, faulty interrupts servicing
> programs, etc. ANYTHING.

In my experience, software debuggers are even less useful
for this class of problem than for most. (Hardware debuggers
are a different breed of cat altogether.) If you're looking
for a race condition or other timing-dependent glitch, the
"probe effect" of a breakpoint or watchpoint is too disruptive
to be of use; the timing is altered and the problem scurries
away from your gaze. Also, such problems are, by their nature,
hard to reproduce: By the time you realize the problem exists
and start prodding it with a debugger, the moving finger has
moved on.

For such nasties, I've had better success with a two-part
approach: I try to construct proofs of correctness for crucial
sections (the degree of formality of the "proof" may vary),
and I build in some kind of event trace to assist post-mortem
analysis. That is, I use a combination of "reading the code"
and "printf debugging," and I find it more effective than
trying to get a debugger to deliver something useful.

Interactive debuggers are occasionally helpful, sometimes
invaluable. But they are certainly not the only debugging
tools in the chest, nor even the sharpest.

--
Eric Sosman
lid