Learning C online?

[jacob navia]

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.

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

 

[Morris Dovey]

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

I'll join the thread because I'm becoming bored and irritated
with this whole business...

Like others here I've routinely debugged code considerably bigger
than 1500 lines by inspection.

The most recent large code base was that of a cable modem with at
least one of most of the interfaces I'd seen in the previous five
years and a number that were new to me. The software I debugged
by inspection - and the hardware I debugged by writing some
special-purpose code to force hardware errors. That special
purpose code was debugged by inspection.

The project before that I debugged the multicast networking
interfaces on an n-tier network monstrosity, again by inspection
of code. After I'd made the first round of code changes, I wrote
some special-purpose code to examine impacts of loading and
timings on overall throughput during actual (production)
operation. This time the special-purpose code was debugged by
inspection and peer review _before_ insertion because the folks
in charge were insistant that I not induce a failure. The results
of that examination were used to produce a heuristic modification
to the multicast interface that caused it continually
self-(re)tune for maximum speed with a an absolute minimum of
loading-induced failures. That code, also, was pre-debugged by
inspection and peer review. I'm not sure how large their code
base is - but I'm absolutely cerain that I worked my way through
several hundred times what you set as the upper limit to debug by
inspection.

There actually are times when the job simply has to be done by
looking at the source and mentally emulating the execution.

I'm not a super brain and I don't have any special powers beyond
persistance and determination to do a first-class job. Sometimes
my head hurts and my stomach churns and my eyes burn - I guess
that's part of what we're paid for.

Is it worth it? Well, I understood that Philips' first order for
the cable modem product was for 10 million units (one just has to
believe that the customer liked what they saw!) and the most
recent word from the stock exchange was that there hasn't yet
been any problem with my multicast heuristics modification.

My conclusion: reading the code, even when there's a lot of it,
can be an effective debugging method for at least some people in
some situations.

Now, can we give the contentiousness and name-calling a rest?

 

[jacob navia]

I'll join the thread because I'm becoming bored and irritated
with this whole business...

Like others here I've routinely debugged code considerably bigger
than 1500 lines by inspection.

The most recent large code base was that of a cable modem with at
least one of most of the interfaces I'd seen in the previous five
years and a number that were new to me. The software I debugged
by inspection - and the hardware I debugged by writing some
special-purpose code to force hardware errors. That special
purpose code was debugged by inspection.

Obvious.

You have been working for years and years in communications/network
sofwtare. You know most of the interfaces, and even if they are "new"
they do more or less the same stuff that you know very well.

The project before that I debugged the multicast networking
interfaces on an n-tier network monstrosity, again by inspection
of code. After I'd made the first round of code changes, I wrote
some special-purpose code to examine impacts of loading and
timings on overall throughput during actual (production)
operation. This time the special-purpose code was debugged by
inspection and peer review _before_ insertion because the folks
in charge were insistant that I not induce a failure. The results
of that examination were used to produce a heuristic modification
to the multicast interface that caused it continually

Peer review is very good yes, but it is surely NOT debugging!
You are confusing peer review, that allows people to get rid of
bugs before they enter the code base, from DEBUGGING, i.e. FINDING
the problem once it is inside the code base!

I am NOT saying that reading the code is bad, or that peer review is
bad, that would be completely absurd. What I am saying is with
some level of complexity the brain is just unable to follow, because
the brain is not a computer!

self-(re)tune for maximum speed with a an absolute minimum of
loading-induced failures. That code, also, was pre-debugged by
inspection and peer review.

The code was subject to a good peer reviw. That is very good method, but
it is a DIFFERENT activity than debugging, see above.

I'm not sure how large their code
base is - but I'm absolutely cerain that I worked my way through
several hundred times what you set as the upper limit to debug by
inspection.

There actually are times when the job simply has to be done by
looking at the source and mentally emulating the execution.

This is very good too, but *it has limits*, and I would say
that the 1500-2000 lines is just a over sized limit!

 

[Nick Keighley]

jacob navia wrote:

I'll join the thread because I'm becoming bored and irritated
with this whole business...

Like others here I've routinely debugged code considerably bigger
than 1500 lines by inspection.

The most recent large code base was that of a cable modem with at
least one of most of the interfaces I'd seen in the previous five
years and a number that were new to me. The software I debugged
by inspection - and the hardware I debugged by writing some
special-purpose code to force hardware errors. That special
purpose code was debugged by inspection.

The project before that I debugged the multicast networking
interfaces on an n-tier network monstrosity, again by inspection
of code. After I'd made the first round of code changes, I wrote
some special-purpose code to examine impacts of loading and
timings on overall throughput during actual (production)
operation. This time the special-purpose code was debugged by
inspection and peer review _before_ insertion because the folks
in charge were insistant that I not induce a failure. The results
of that examination were used to produce a heuristic modification
to the multicast interface that caused it continually
self-(re)tune for maximum speed with a an absolute minimum of
loading-induced failures. That code, also, was pre-debugged by
inspection and peer review. I'm not sure how large their code
base is - but I'm absolutely cerain that I worked my way through
several hundred times what you set as the upper limit to debug by
inspection.

There actually are times when the job simply has to be done by
looking at the source and mentally emulating the execution.

I'm not a super brain and I don't have any special powers beyond
persistance and determination to do a first-class job. Sometimes
my head hurts and my stomach churns and my eyes burn - I guess
that's part of what we're paid for.

Is it worth it? Well, I understood that Philips' first order for
the cable modem product was for 10 million units (one just has to
believe that the customer liked what they saw!) and the most
recent word from the stock exchange was that there hasn't yet
been any problem with my multicast heuristics modification.

My conclusion: reading the code, even when there's a lot of it,
can be an effective debugging method for at least some people in
some situations.

Now, can we give the contentiousness and name-calling a rest?

excellent post. I'll run the risk of being acused of joining "The
Clique"!

 

[Richard]

I'll join the thread because I'm becoming bored and irritated
with this whole business...

Like others here I've routinely debugged code considerably bigger
than 1500 lines by inspection.

And like others, you have totally failed to recognise the reasons and
criteria for stating the importance of a debugger.

You have routinely debugged code you are very familiar with.

You continually confuse peer review with post release bug finding in a
foreign code bade.

You continually fail to recognise that your reading technique can ONLY be
facilitated in the great majority of cases by ALSO using a debugger to
alter the program state at critical moments. it would take nothing
away. And that is reason enough for using one for a professional - it
can only improve the debugging session in most cases.

 

[Nick Keighley]

Obvious.

You have been working for years and years in communications/network
sofwtare. You know most of the interfaces, and even if they are "new"
they do more or less the same stuff that you know very well.


Peer review is very good yes, but it is surely NOT debugging!

and you wonder why people get p***ed off with you.
Debugging is the detection, isolation and removal
of errors. It can be done in avariety of ways.
Including walk thrus and desk checks.

You are confusing peer review, that allows people to get rid of
bugs before they enter the code base, from DEBUGGING, i.e. FINDING
the problem once it is inside the code base!

often the aim is not to let them in the first place.

I am NOT saying that reading the code is bad, or that peer review is
bad, that would be completely absurd. What I am saying is with
some level of complexity the brain is just unable to follow, because
the brain is not a computer!

yet Eric claims he can. Is he mistaken?

<snip>

look Jacob, your claim has been refuted suffiently often
that you *know* it isn't true. So why repeat it? This is
trolling.

so for now v-plonk.

 

[Richard]

excellent post. I'll run the risk of being acused of joining "The
Clique"!

It was not an excellent post in any sense. It was a ridiculously
engineered example of something that almost certainly would have been
done quicker and more efficiently using a HW debugger.

Lets look at the summary:

,----
| >>
| >> My conclusion: reading the code, even when there's a lot of it,
| >> can be an effective debugging method for at least some people in
| >> some situations.
`----

It CAN be an effective debugging technique.In a minority of cases when
you are familiar with the code. Now lets ask what using a HW debugger in
conjunction with this technique does? Answer : it enhances it.

Prior to debuggers reading was the ONLY way. It was slow, error prone
and tedious. It is WHY debuggers exist.

Any programmer that told me he does not need a debugger to HELP or
ENHANCE his debugging in the majority of situations would be judged as
either a genius or a bullshitter and time waster. And I never met many
geniuses. Note the words "majority", "help" and "enhance" before you
start ranting about how you once found a bug by reading 3000 page
printout while sat on the toilet.

 

[Richard]

often the aim is not to let them in the first place.

Your conceit is astonishing. You are advising us that the aim is not to
let bugs in in the first place? Really? CLC is exceeding itself in this
thread.

Stop the clock everyone! We've been doing it all wrong!

Nick has proven that debuggers are useless!

Just don't make any bugs in the first place!!!!

 

[Richard Heathfield]

jacob navia said:

Peer review is very good yes, but it is surely NOT debugging!

Yes, it is. It's one way to remove bugs from code - i.e. to "de-bug" the
code. It is, of course, not the only way.

You are confusing peer review, that allows people to get rid of
bugs before they enter the code base, from DEBUGGING, i.e. FINDING
the problem once it is inside the code base!

This may be a definition clash. I view "the code base" as "all the code
that has so far been written for the project", whereas you seem to think
that "the code base" means code that has been through peer review. Neither
view is inherently wrong, but they are rather different from each other.

The way I see it, the sooner you get the bugs out, the better. If you can
get them out while you're typing them, good! If you can get some more out
during your trial executions of the code, that's great! If you can get
even more out at peer review, that's wonderful! Just as long as you get
them out. And if they get into what /you/ call the code base, that's bad,
but presumably there's still the test phase (pace, TDD folks!). It's a bit
of a last-ditch time at which to do debugging, but hey, as long as it's
done, that's what matters. And *all* of these are attempts to remove bugs
from - i.e. to "de-bug" - the code.

I am NOT saying that reading the code is bad, or that peer review is
bad,

I recognise this.

that would be completely absurd. What I am saying is with
some level of complexity the brain is just unable to follow, because
the brain is not a computer!

I agree that there is an upper limit to what the brain can tackle in a
reasonable time. I think the limit is higher than you claim, however, and
I also think that modular development can ease this problem. Indeed, that
is the whole *point* of modular development.

<snip>

 

[Morris Dovey]

Obvious.

Thanks. I just ran wc over the include/*.h and src/*.c for a
total of 33134 lines.

You have been working for years and years in communications/network
sofwtare. You know most of the interfaces, and even if they are "new"
they do more or less the same stuff that you know very well.

Actually, the previous project had been my first network coding
experience. This project was my first experience actually
programming MAC and PHY. It seemed pretty new to me!

Peer review is very good yes, but it is surely NOT debugging!
You are confusing peer review, that allows people to get rid of
bugs before they enter the code base, from DEBUGGING, i.e. FINDING
the problem once it is inside the code base!

Consultants are always "bad guys". People look at you and think
(and sometimes say right out loud): "There goes the money for my
bonus." Design and code reviews tend to be conducted in an
atmosphere that provides strong motivation to remove the bugs
beforehand. I did.

I am NOT saying that reading the code is bad, or that peer review is
bad, that would be completely absurd. What I am saying is with
some level of complexity the brain is just unable to follow, because
the brain is not a computer!

Relax a bit - the code all came out of somebody's brain. It can
all go back in, and probably with more ease than it came out.
That's not to say that it's always easy, just that it's possible.

One of the things that was most fun about that project was that I
discovered I could identify the authors of the code I was reading
- even to the point of noticing when different parts of a module
had been written by different people. Baffled the hell out of 'em
when I did that, which gave me a few chuckles.

What that told me, though, is that a part of the process is
"getting inside the author's head" and developing some feel for
how they approach problems - and making that a part of the
cognative process. There is more information in a piece of code
than just a sequence of machine operations if you're open to it.

The code was subject to a good peer reviw. That is very good method, but
it is a DIFFERENT activity than debugging, see above.

Peer reviews provide critical analysis and spot flaws. The folks
who reviewed my stuff never let go until they were convinced the
rationale, the design, and the code were absolutely clean and
well-understood by all reviewers. I was always nervous going in
and relieved coming out. The worst they ever found in my code

This is very good too, but *it has limits*, and I would say
that the 1500-2000 lines is just a over sized limit!

Give your brain more credit and, perhaps, be more willing to ask
more of it. I suspect you're capable of much more than you've
been willing to try. (Not a criticism, rather an observation that
the human brain is an amazingly capable processor!)

 

[Keith Thompson]

I'm old fashioned. I know from experience and general data gathered in
years of industry that K&R2 is *generally* the best there is for new C
programmers. It was for me and I am yet to meet anyone who didn't get at
least something from it.

K&R2 is excellent for a new C programmer with some programming
experience. It's been said that it may be too advanced for someone
who's completely new to programming. (I offer no opinion on the
latter statement; I'm just pointing out a distinction that you may
have missed.)

 

[Antoninus Twink]

jacob navia said:



Mr Navia, if you must address me in person, kindly have the courtesy to
address me properly.

Perhaps Jacob would find it easier to be polite to you if you weren't
orchestrating a vicious campaign of character assassination against him,
partly through anonymous sock puppets. Or if the memory of you making
grotesque allegations against his daughter wasn't fresh in his mind. Or
if you weren't such an opinionated, self-righteous, puffed-up, pompous
dick.

I did not post an answer to your previous reply ("So, You CITE me there
writing...") because I had already posted another reply in the same
thread, explaining my point of view with regard to the relationship
between reading and debugging, so it seemed superfluous to write the same
stuff all over again in a reply to your article.

What's more, just as you have the right either to reply or not to reply to
particular articles, so do I have that right. There is no need for me to
reply to every article, not even every article that is a reply to one of
mine. (If everyone replied to every reply to their articles, ... well, do
the math.) You get to decide which articles you write, and I get to decide
which articles I write.

Of course, we all know the long history of you making nasty, unfounded
accusations, then disappearing and playing the innocent when the fur
starts flying, like a sanctimonious choir-boy who stops pulling a face a
split-second before the music director turns to look at him.

 

[Richard]

Perhaps Jacob would find it easier to be polite to you if you weren't
orchestrating a vicious campaign of character assassination against him,
partly through anonymous sock puppets. Or if the memory of you making
grotesque allegations against his daughter wasn't fresh in his mind. Or
if you weren't such an opinionated, self-righteous, puffed-up, pompous
dick.


Of course, we all know the long history of you making nasty, unfounded
accusations, then disappearing and playing the innocent when the fur
starts flying, like a sanctimonious choir-boy who stops pulling a face a
split-second before the music director turns to look at him.

LOL. Spot on. He almost had me fooled a day or two ago before he turned
his true face outwards after Richard Bos decided to start slurring
Jacobs competence with gross misrepresentations of what Jacob actually
said. This group is so unique. Today has blown me away. We have adult
programmers telling us it would be "preferable not to make bugs" than
use a debugger! What a revelation! Only in clc! I never saw such a bunch
of pretentious dickheads.

 

[Flash Gordon]

Richard Heathfield wrote, On 13/03/08 12:07:

Zach said:


See also http://clc-wiki.net/wiki/ which contains a K&R answers section.

You can also post questions about the answers that are on the CLC Wiki.
At least some of the people who wrote those answers still post here, and
new alternative solutions, improvements, and answers to questions which
do not have them are always welcome.

 

[jacob navia]

LOL. Spot on. He almost had me fooled a day or two ago before he turned
his true face outwards after Richard Bos decided to start slurring
Jacobs competence with gross misrepresentations of what Jacob actually
said. This group is so unique. Today has blown me away. We have adult
programmers telling us it would be "preferable not to make bugs" than
use a debugger! What a revelation! Only in clc! I never saw such a bunch
of pretentious dickheads.

I am amazed too. Better not to introduce bugs. GREAT!

Just a small detail missing: they will not tell us how
they do that... Of course they are infallible, can debug
assembler without even seeing the program, huge code
bases without a debugger, never make any mistake, etc
etc.

Reality is a little bit different. Heathfield has a lot
of errata in his book, even if he was writing it with
others. Everybody knows that bugs are inevitable, and
nobody believes this "I can debug without a debugger" stuff.

This reminds me about the stack discussion...

"There is no stack in C"...

I think that the discussion about the stack cleared that.

I will start a new series about debuggers then...

 

[Richard Heathfield]

Richard said:

LOL. Spot on.

Wrong, actually. Your troll friend has made several errors of fact in the
text you quote. If you were as critical of others as you are of me, you
would have known this. If you want to be taken seriously (and it's
difficult to take you seriously when you attack people just for having
different ways of working to you), I suggest that you check your facts
before posting in future.

 

[Richard Heathfield]

jacob navia said:

I am amazed too. Better not to introduce bugs. GREAT!

You disagree?

Just a small detail missing: they will not tell us how
they do that...

Actually, lots of ways to reduce the number of bugs introduced into code
are shared in this newsgroup on a daily basis. Nobody is claiming,
however, that this amount can be reduced to zero.

Of course they are infallible, can debug
assembler without even seeing the program, huge code
bases without a debugger, never make any mistake, etc
etc.

No, nobody is infallible, and debugging a program without seeing it is very
difficult (although I *have* done it on occasion - I don't expect you to
believe me, of course). I have certainly debugged what you consider to be
impossibly large code bases without using a debugger. I can't claim that
I've never made a mistake, though, and I don't think there's anyone here
who claims that. It is *you* who claim that people claim they never make a
mistake. Your claim is wrong. You are mistaken.

Reality is a little bit different. Heathfield has a lot
of errata in his book, even if he was writing it with
others.

Yes, that is unfortunately the case. But in fact it demonstrates that bugs
/can/ be found without a debugger. Every erratum is a bug in the book that
has been *found* - and a great many of them were found without a debugger
(I know this because I found many of them myself). I have not been
informed of *any* bugs in that book where the finder required a debugger
to discover them. Incidentally, the book is considerably longer than 2000
lines.

Everybody knows that bugs are inevitable, and
Right.

nobody believes this "I can debug without a debugger" stuff.

....except those who've done it, of course, which seems to be most of us.

This reminds me about the stack discussion...

Yes, you never understood that one, either.

"There is no stack in C"...

The C language specification is written in such a way as not to require C
implementations to use a stack. If you disagree with that, let's see
chapter and verse. If you agree, however, then you are agreeing with the
very people you ridicule.

I think that the discussion about the stack cleared that.

If it had done so, you would now understand. Since you do not understand,
it has not done so.

I will start a new series about debuggers then...

Oh dear, here we go again.

 

[Bartc]

jacob navia said:

Yes, you never understood that one, either.


The C language specification is written in such a way as not to require C
implementations to use a stack. If you disagree with that, let's see
chapter and verse. If you agree, however, then you are agreeing with the
very people you ridicule.

These Standards have a lot to answer for.

My C99 spec doesn't seem to mention the word 'Computer' anywhere either, but
I bet a computer does figure in most implementations.

 

[Richard]

No. You were being a pedantic fool once more.

But most do. So they are on topic when discussing people debugging
standard compliant C using a tool such as a DEBUGGER! .......

You ridicule yourself with your pretentious and quite ridiculous
posturing.

These Standards have a lot to answer for.

My C99 spec doesn't seem to mention the word 'Computer' anywhere either, but
I bet a computer does figure in most implementations.

Not for these lads. They can compile and "debug" a 3000 line program of
other peoples code for up to 10 years into a run by merely reading the
printout. This is the type of legends you are dealing with here. Not
only that but they take into account all issues which might come from
float rounding, integer overflows, bugs in linked libraries, memory
allocation failures, lost memory etc. Amazing eh? I put it all down to
them reading Knuth at the age of 6.

 

[Richard Heathfield]

Bartc said:

These Standards have a lot to answer for.

My C99 spec doesn't seem to mention the word 'Computer' anywhere either,
but I bet a computer does figure in most implementations.

The Standard refers many times to computations, i.e. things that are done
by a computer. Also, C89 reads in part: "The standard was developed by the
X3J11 Technical Committee on the C Programming Language under project
381-D by American National Standards Committee on Computers and
Information Processing (X3)."

Nevertheless, a computer is not, strictly speaking, required for a C
implementation. IIRC Peter Seebach once claimed that he is a conforming C
implementation (although it's a somewhat suspect claim since his
conformance documentation doesn't seem to be available). There is nothing
intrinsically impossible about this. It would be perfectly possible,
albeit unwieldy, to implement C on a model railway, using nothing but
normal track (and, I think, three different kinds of points). It sounds
utterly bizarre, but it is nevertheless true.

(The group's trolls will obviously enjoy mocking that one, but only because
they will utterly fail to understand my point.)