Debuggers

Discussion in 'C Programming' started by jacob navia, Mar 13, 2008.

  1. jacob navia

    jacob navia Guest

    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, Mar 13, 2008
    #1
    1. Advertising

  2. 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$-online.net>
    Johannes Bauer, Mar 13, 2008
    #2
    1. Advertising

  3. 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.
    Ben Bacarisse, Mar 13, 2008
    #3
  4. jacob navia

    santosh Guest

    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.
    santosh, Mar 13, 2008
    #4
  5. jacob navia

    Richard Guest

    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.
    Richard, Mar 13, 2008
    #5
  6. jacob navia

    Richard Guest

    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.
    Richard, Mar 13, 2008
    #6
  7. jacob navia

    Chris Dollin Guest

    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
    Chris Dollin, Mar 13, 2008
    #7
  8. 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
    Joachim Schmitz, Mar 13, 2008
    #8
  9. 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
    Richard Heathfield, Mar 13, 2008
    #9
  10. jacob navia

    Eric Sosman Guest

    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
    Eric Sosman, Mar 13, 2008
    #10
  11. jacob navia

    santosh Guest

    Richard wrote:
    > santosh <> writes:
    >> jacob navia wrote:


    <snip>

    >>> 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.


    For a simple program mentally working through the source could be
    equivalent to running it under a debugger, ignoring the possibility of
    errors in code outside the program, the debugger, and the hardware.

    <snip>
    santosh, Mar 13, 2008
    #11
  12. jacob navia

    Richard Guest

    "Joachim Schmitz" <> 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.

    > a lie is very different from a misinterpretatation.


    Any fool can hide behind that. Bos was telling porkies. He
    misinterpreted nothing. How the hell can you misinterpret someone
    talking about debugging for someone reading code?

    >
    >> 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.


    Is it equally (*)unacceptable to post untruths in order to libel
    someone like Jacob and his work?

    >
    >> 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.


    No one said any different. But swap "enable" to "facilitate".

    > You need to write/modify the code to debug it, i.e. to remove the bug.


    You are actually telling us that one needs to modify code to remove the
    bug? Wowola - a true mind altering fact :-;

    > Without reading and understanding the code it won't be possible to find any
    > bug.


    Wow! The things we learn here. Even if its not 100% true, its close
    enough. I have fixed loads of bugs on big systems without understanding
    the bigger picture. A debugger allows one to quickly binary chop into
    the point causing the issue. Examine localised issue. Alter. Fix. Done.

    >
    > 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,


    What a load of mindless word games. The debugger is a utility to debug
    with. You do indeed debug with a debugger. It's why its called a
    debugger....

    > provided (once again) that you read and understand the code.


    Which is easier done in context in the debugger on any sizeable code base....

    > A debugger may be a great help in finding the bug. On the other hand
    > sometimes it even hinders finding it.


    When? Or will you come out with another of these one in a million
    situations? Assuming the debugger supports your platform and runtime
    type there is no issue generally.

    Why do clc members always look for those one in a million urban myth
    type examples to back up their extreme views?

    >
    >> 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.


    Yes it is. Because only from ones own experience can one judge the
    claims made by others. And boy are there some claims in clc!

    > 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)


    Of course. But not the issue at hand.

    >
    >> 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.


    You are now advising on what documentation is needed?

    > Lacking that you can only resort to read the code to reverse engineer that
    > description


    Huh? What does that have to do with anything discussed here? Debugging
    involves reading the code in the debugger at the same time as examining
    run time values.

    I have modified/fixed loads of code with crappy documentation, by
    ..... using a debugger to trap the errors, and modifying runtime parameters
    to check the extremes - impossible to do efficiently by "reading the
    code" only.

    These claims are, frankly, ludicrous to the extreme and I for one don't
    believe half of them. If they are being serious then they are either
    stuck in the past and have no idea what a modern debugger can do or are
    purposely dogmatic and losing their companies a whole pile of money by
    using their time totally inefficiently.

    Yes, I know its not politically correct in clc to question any of the
    claims made by clique regulars, but really. Some of the stances taken
    here regarding "general practice" are ridiculous.

    Of course there are situations where a debugger might not be
    perfect. Where a quick glance at the code reveals an obvious error or
    where the guy who wrote the code knows off the top of his head where the
    error lies. But these are not the general conditions we are
    discussing. We are discussing large, foreign code bases.

    I know there will be the "are you calling X a liar, you owe him an
    apology" crowd culling me now. "Lie" is too big a word - exaggerating
    might be more close to the mark.
    Richard, Mar 13, 2008
    #12
  13. jacob navia

    Richard Guest

    Eric Sosman <> writes:

    > 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.


    You are trolling and I claim my 5 dollars.

    What an absolutely mind blowingly ridiculous claim.

    "For MOST programs an interactive debugger is a waste of time."

    I've read some nonsense in my time but you surely top it.

    The sad thing is that I think you are serious. Even worse would be if
    you expect any experienced programmer other than the clc mob to believe
    you.
    Richard, Mar 13, 2008
    #13
  14. jacob navia

    Richard Guest

    santosh <> writes:

    > Richard wrote:
    >> santosh <> writes:
    >>> jacob navia wrote:

    >
    > <snip>
    >
    >>>> 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.

    >
    > For a simple program mentally working through the source could be
    > equivalent to running it under a debugger, ignoring the possibility of
    > errors in code outside the program, the debugger, and the hardware.
    >
    > <snip>


    Once again : yes. For a very small short lived program yes it is almost
    the equivalent. For anything of substance it is not. The eyes miss
    things in printed code that a colour coded debugger output would make
    very obvious.

    I'm not sure why you make this fairly obvious and trivial point.
    Richard, Mar 13, 2008
    #14
  15. Eric Sosman said:

    > jacob navia wrote:


    <snip>

    >> 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.


    "Mediocrity does not see higher than itself." - Sir Arthur Conan-Doyle

    --
    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
    Richard Heathfield, Mar 13, 2008
    #15
  16. jacob navia

    jacob navia Guest

    Richard Heathfield wrote:
    > Eric Sosman said:
    >
    >> jacob navia wrote:

    >
    > <snip>
    >
    >>> 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.

    >
    > "Mediocrity does not see higher than itself." - Sir Arthur Conan-Doyle
    >


    Well this explains a lot of your behavior then...


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Mar 13, 2008
    #16
  17. Richard <> writes:

    > 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.

    <and, moved:>
    > Oh for goodness sake. It is "possible" to do anything.


    So why reply to me? It was Jacob that claimed something was
    impossible. Why not reply to him saying "anything is possible"? I am
    *not* saying that is was easy or desirable or my preferred option,
    just that this is what people had to do.

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


    Curiously, my second job was porting Unix (user-space utilities) to a
    new micro-coded architecture. The debugger (sdb at the time) was last
    on the porting list because it needed micro-code and compiler support
    that could not be made available until later. We (a team of three)
    had to do the port and debug the code (including a large CAD
    application) without a debugger. These things happen (or at least
    they did, once) and it just seems absurd to say that it is
    impossible. Most of this was C code, in case there is any chance or
    marginal topicality left.

    <snip>
    >>> 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!!!!!!!!!!!!!!!!!!!


    Does that mean you can't find a counter-argument? It was Jacob that
    made the absolutist claim which has obvious counter-examples. All I
    did was point that out.

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


    Did Jacob not mean "impossible"? If you think he was playing word
    games by saying that when he did not mean it, then I am with you --
    people should not do that. If someone claims X is impossible and
    you've done X, would you just let it go lest you be accused of playing
    word games?

    --
    Ben.
    Ben Bacarisse, Mar 13, 2008
    #17
  18. In article <>,
    Ben Bacarisse <> wrote:

    >Did Jacob not mean "impossible"?


    He was exaggerating. There was some truth in what he said, but he
    overstated it. There's no point basing a long argument on something
    like that.

    -- Richard
    --
    :wq
    Richard Tobin, Mar 13, 2008
    #18
  19. jacob navia

    CBFalconer Guest

    Navia offshoots (was: Debuggers)

    jacob navia wrote:
    >

    .... 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?


    Who knows. We do know, however, that it is extremely easy to drive
    you into a paroxysm, where you run off and create new threads,
    totally unlinked to the old thread, to carry your opinion. You may
    notice that the prime effect of this is to clutter up the
    newsgroup, usually with something that is off-topic to begin with,
    and often carries evil insults. Your 'new thread creation'
    tendency also makes it awkward for sensible readers to PLONK all
    those threads.

    You will notice that this, although carrying a revised title, is
    still linked to your new thread (check the references line).

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Mar 13, 2008
    #19
  20. On 13 Mar, 15:02, (Richard Tobin) wrote:
    > In article <>,
    > Ben Bacarisse  <> wrote:


    > >Did Jacob not mean "impossible"?

    >
    > He was exaggerating.  There was some truth in what he said, but he
    > overstated it.  There's no point basing a long argument on something
    > like that.


    he's a computer programmer posting to a technical forum.
    Perhaps he should learn to be more precise.


    --
    Nick Keighley
    Nick Keighley, Mar 13, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marco Lorenzini
    Replies:
    0
    Views:
    380
    Marco Lorenzini
    May 13, 2004
  2. R. Bernstein
    Replies:
    18
    Views:
    565
  3. infinity

    C Debuggers?

    infinity, Mar 15, 2005, in forum: C Programming
    Replies:
    2
    Views:
    335
  4. jacob navia

    How do debuggers work?

    jacob navia, Mar 18, 2008, in forum: C Programming
    Replies:
    30
    Views:
    1,062
  5. TheSaint

    Debuggers

    TheSaint, Jun 13, 2008, in forum: Python
    Replies:
    3
    Views:
    313
    R. Bernstein
    Jun 17, 2008
Loading...

Share This Page