Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Learning C

Thread Tools

Learning C

Richard G. Riley
Posts: n/a
On 2006-03-12, Ian Collins <(E-Mail Removed)> wrote:
> Richard G. Riley wrote:
>> On 2006-03-11, Keith Thompson <(E-Mail Removed)> wrote:
>>>If I might summarize:
>>>Richard G. Riley really likes debuggers. Not everyone else likes them
>>>as much as Richard does.
>>>I believe that covers all the relevant points.

>> Very droll.
>> But not at all what the crux of this is about : what its about is a
>> one way of working which can dramatically speed up ones familiarity
>> with a system. I find it terrifying that there seems to be a fair
>> number of programmers here who think a debugger is "only for finding bugs"
>> : it is a limited and naive view.

> There is the middle ground, read the code first and step tough bits you
> can't sus out in the debugger. A decent source browser (one that


100% of course. *Nothing* is as good as a good clear printout for an
overview and a familiarity. Hell, I print out man pages still.

> you callers and callees) is a better tool for the job, it gives you an
> overview of the code, rather than the details of one part of it.
> Using a debugger as the main tool for familiarising one's self with a
> large body of code is a bit like using a microscope to read a book.

I'm afraid that due to some of the replies I might have become a bit
exasperated and come across as a bit of a fanatic

But to close and to summarise some points which a lot of posters dont
seem to be aware of - or at least it appears that way from their
"debuggers are only occasional useful" replies -

1) A debugger can give you that high level overview too
2) It has cross reference facilities for definition finding
3) Ability to give symbolic representation to data
4) Ability to tweak at runtime to force unlikely conditions
5) Abilitiy to see entire dataset : not that determined useful by the
original programmer
6) Watchpoints & HW breakpoints to isolate required conditions.
7) Shows types : reveals bad casts & conversions very quickly in the

There are more. A good print out is good if for nothing else than
sitting on the jacks having a read Or annotation. The combo of a
good debugger with the experience of how to use it and possibly a
profiler is nirvana for a C programmer working on a large project.

I've seen old systems where the code is simply unreadable :
multistatements per line, single letter variable names, cast city :
code like this can be a nightmare to read from a printout - it is
useful to watch the program run. Yes, printfs* can be useful if
you have the knowledge and the facility to insert them.

(*) Or home brew multi-platform/interface compatible logging system
like Linux's klogd.

One last point about your microscope comment : this is only true if
you *step* every line. You dont. You place strategic break points at
the page or chapter you are interested in : after all, a C program is
hardly a novel - thought it is a schematic

And to anyone that got this far that isnt totally bored by the whole
thing : consider this. You see a function in a source browser :
are you not interested in HOW it was called? Why it was called? You can
guess from 30000 pages of printout or from a call hierachy in a source
analysys tool or IDE : but its 2 seconds work to set a break point
there and examine a few call stacks.

Yes, I'm an advocate. And astonished by the claims of some who say
they havent used a debugger more than twice in over 20 years of C programming.


Reply With Quote
Richard G. Riley
Posts: n/a
On 2006-03-12, Nick Keighley <(E-Mail Removed)> wrote:
> no. Put an assert() in. A modified variable is just for today. An
> approriate
> assert() lasts forever. Next year when someone casts doubt on the same
> function, you simply look at the func() source code and say "nope,
> can't
> be a divide by zero because there's an assert() to check for that". Fix
> it
> once, never touch it again.

Thats not the example I gave. I gave the example to force the divide
by zero error : with no added code which changes the footprint between
runtime and debug models. To expand a bit, I might want to check a
deeply embedded function can handle an integer limit or a null
pointer. One very important issue
here is that I dont do this all the time - only when its deep in a
system where a quick glance cant quarentee the absence of such
"limits". I might want to call "convertBitmap()" with option 3 for GIF
since the test data framework didnt incude that option. Or 6 which is
not yet implemented.

Bottom line is that also, some systems dont want to exit : they want
to handle the assert condition more generously. assert is one up from
printf mind you. At least you can compile it out without running
around changing all your source. Not that I agree with code footprint
which is different between "real" and "development".

Also, how many times have we found


as opposed to "assert(a);a++" in some remote rarely called routine?

Bad? Yes. But **** happens.

If what you want is required then yes, an assert is useful.

> a debugger war is much more fun...

It can be.. (ps this is far from OT : it is about using C language mechanisms
for debugging aid which overrule the need for a HW/SW debugger). If it
was in the std group then yes.

>> >> > Maybe I'll even get my debugger out and step through a program
>> >> > sometime to see if it brings me any insights. Maybe you should try
>> >> > a "debugger free day" and try and see what you have to do to manage
>> >> > without. Try reasoning about the program. Consider invariants and
>> >> > post/pre conditions. Try adding asserts etc.
>> >>
>> >> If you recall I did mention that a home brew logging system is
>> >> prefential to printf :
>> >
>> > where did the words "homebrew logging system" appear in the paragraph
>> > above? I did write a fairly blunt paragraph here. And then thought
>> > better of it. Do you know what an invarient is? Design by contract?

>> I used those words. Its when you wrap whatever underlying logging system is
>> convenient to you in a fairly generic calling interface : so you could
>> log to files, text consoles, window systems whatever without changing
>> the calling code.

> I note you didn't say if you knew what "Design by Contract" meant.

It has nothing to do with what I am advocating here. And so I wont get
dragged into a terminology war. I'm not talking about designing
anything here. And if I wanted to bluff, google is a mere keypress away

Remember that the crux of this is that I'm saying it can be
advantageous for someone wanting to familiarise themself with a system
to see it runing under a good debugger. You claimed this as "bizarre".

>> >> A debugger isnt the only tool : and I never said it was. What it
>> >> can do is allow you to see the flow of an application while watching
>> >> live data, allow you to modify that data
>> >
>> > never felt the need. Not since compilers got fast enough to run during
>> > the day.

>> I really dont understand this. What has that got to do with a debugger?

> I've modified variables using the debugger (the "debugger" actually had
> toggle switches...) when the run time of the compiler was significant.
> If it
> took hours to recompile your code then machine code patches and
> register
> hacking was acceptable. It is no longer necessary (well, sometimes).

You must work on very small systems. I would never counter someone
modifying code here there and everywhere to *find* a bug when you can
get the same effect in less time without modifying the code.

What are toggle switches? What is a machine code patch in this
context? I would rarely advocate register hacking : the whole point of
a debugger is that it gives symbolic access to your system variables
and messing with registers is not required.

>> >> and to examine and ensure
>> >> data typing is consistant from skillful use of register/pointer/memory
>> >> examinations : it is why they exist.
>> >
>> > you examine registers? On a deeply embedded system, ok. But a
>> >> server?

>> I also mentioned memory and pointers. And yes I do. Very useful in
>> debugging big C systems.

> wow. Culture Shockville. To my shame I couldn't even tell you what
> registers
> my platform has without STFWing. Ok that's a project for today.
>> >> The whole crux here is you doubting
>> >> that stepping an existing app can help a user understand it : after
>> >> many, many and varied projects on various platforms in various
>> >> languages I find it incredulous how you could doubt this would be
>> >> beneficial. In order to even put in these printfs() you need some
>> >> understanding of whats going :

>> > I'd say the same went (in spades) for stepping. You've got to know
>> > where
>> > to step. There's source code, case tools, source browsers, source code.
>> > I've even resorted to grep to find callers of functions.

>> grep is ok : if I dont have a decent IDE I use something like emacs
>> tags. I have used grep in about 15 years

> ok it's a tool of desparation. You * never* use grep?!

I used it today to find where a certain daemon was in a boot hierarchy
: nice.

OK, lets call it a day.

> --
> Nick Keighley
> Testing can show the presense of bugs, but not their absence.
> -- Dijkstra

Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
[I'm learning C]: Learning to use ucontext Andrey Popp C Programming 5 01-31-2012 01:05 AM
Learning C and Learning Make/Configure/Building/Linking Hal Vaughan C Programming 7 03-21-2006 05:07 PM
e-learning, (collaborative learning environment) collinm Java 1 09-08-2005 09:52 PM
Learning about SMS technology... VM Wireless Networking 2 07-02-2004 02:36 PM
learning VHDL Vilvox VHDL 5 07-20-2003 08:59 AM