Seriously struggling with C

[CBFalconer]

.... snip ...

It must be a personal thing. For me the debugger is as crucual a
part as the editor : I would normally always step through the
debugger just to sniff out any issues with uninitialised stuff,
pointer run throughs etc. Its why IDEs put so much effort into the
debugger part these days.

Yes, I can vaguely remember doing such things about 25 or 30 years
ago. I outgrew it. I find a sound design and functional breakdown
works much better.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Chris Dollin]

You are discussing rationally so lets stick with this. Everything you
have just said is exactly what I mean by using a debugger. A debugger
isnt only there to locate a point of failure although clearly that is
a major use. It can also be used, as I have repeatedly stated, to test
the system at run time. You can even connect to running processes in
most systems.

I'm sure you can. You don't make it clear in "It can also be used, as I
have repeatedly stated, to test the system at run time" whether you mean
manual or automated testing. Dinking around by hand at run-time with a
debugger would strike me as an approach of last resort. Doing so
/routinely/ strikes me as an act of madness - I mean, I'm fallible
enough already.

[This is different, as far as I can tell, from Chris Hill's description
of automated testing using ICEs etc.]

I *always* use a debugger to run through any meaningful critical
code. It enables me to cast an eye over memory, stacks, locals etc. It
is an added safety barrier beyond my own smug ability to write error
free code

Well, I don't know what you're doing; I've just never been in a situation
where this would be helpful. I'm under no illusions about my ability to
write error-free code, it's just that using a debugger doesn't give me
value for money.

What you describe sounds perfectly sensible - but I wouldn't describe
it as "using a debugger"; I think this is the disconnect.

[I don't know if I'd call the tools you mention "debuggers", either, but
it's too late to know for sure whether I wouldn't have /before/ this
discussion.]

Debugger. Eclipse "debugger". gdb. All debuggers.

debuggers (and why is the Eclipse debugger awarded scare-quotes?) ...

All code development tools.

.... not (necessaily) debuggers: there's a difference here.

All very much used in any real SW development cycle.

There are other approaches than routine manual use of debuggers.

 

[Richard G. Riley]

I'm sure you can. You don't make it clear in "It can also be used, as I
have repeatedly stated, to test the system at run time" whether you mean
manual or automated testing. Dinking around by hand at run-time with a
debugger would strike me as an approach of last resort. Doing so

Connecting to external processes is more rare, I grant you.

/routinely/ strikes me as an act of madness - I mean, I'm fallible
enough already.

lets not get stuck on connecting to remote processes : lets keep it to
using the debugger to test and check new code.

[This is different, as far as I can tell, from Chris Hill's description
of automated testing using ICEs etc.]

I *always* use a debugger to run through any meaningful critical
code. It enables me to cast an eye over memory, stacks, locals etc. It
is an added safety barrier beyond my own smug ability to write error
free code

Well, I don't know what you're doing; I've just never been in a situation
where this would be helpful. I'm under no illusions about my ability to
write error-free code, it's just that using a debugger doesn't give me
value for money.

We must come from different schools of thought. I and every programmer
I have ever worked with routinely step through code alone or with a
colleague to check boundary conditions, memory initialisations etc. It
is a bedrock of any development I have done. Using break expressions
means I can put in wierd and wonderful parameters and have the
debugger break when a function is suddenly passed something it doesnt
know how to deal with. We are, after all, fallible.

What you describe sounds perfectly sensible - but I wouldn't describe
it as "using a debugger"; I think this is the disconnect.

[I don't know if I'd call the tools you mention "debuggers", either, but
it's too late to know for sure whether I wouldn't have /before/ this
discussion.]

Debugger. Eclipse "debugger". gdb. All debuggers.

debuggers (and why is the Eclipse debugger awarded scare-quotes?) ...

All code development tools.

... not (necessaily) debuggers: there's a difference here.

Debugging is part of development in my world. maybe we are talking
nomenclature differences here?

There are other approaches than routine manual use of debuggers.

Such as? An initial use of a debugger to monitor a programs progress
can show up lots of issues as well as facilitating routines boundary
tests. It just makes plain sense.

 

[Ben Bacarisse]

It is very common in (of course) variable declarations and also
declarations and assignments in the initialising clause of for loops

e.g

for(i=0,j=2;check(i,j);i++,j++);

I'd write

for (i = 0; check(i, i + 2); i++);

There are cases (though I can't think of any right now!) where the
relationship between control variables is too complex (or expensive) to
capture, but when you can, I think having one is clearer.

 

[Chris Hills]

I think this may be the "something different". When I say "use the
debugger" I mean a human working interactively with a tool to locate
a point of failure in a system, by placing break/watch-points on
locations/triggers and looking with the eyes at the machine state.

This is also a good use of a debugger.

What you describe sounds perfectly sensible - but I wouldn't describe
it as "using a debugger"; I think this is the disconnect.

[I don't know if I'd call the tools you mention "debuggers", either, but
it's too late to know for sure whether I wouldn't have /before/ this
discussion.]

It depends some are ICE. I tend to cal JTAG and BDM "Debuggers" as
opposed to ICE. At one time people refereed to JTAG as an ICE or
Emulator.

 

[Ingo Menger]

Greetings friends,

This semester I have started a course in C programming. I was moving
along fine until I reached to the topic of loops (feeling embarrassed
among you elite programmers).
[...]
What ticks me off is that
other kids are getting this stuff easily, while I am having a hard
time.

It is possible, that you have difficulties with loops because you think
functional, not imperative. In fact, there are (serious) programming
languages like for example Haskell, that don't have any loop syntax.
Someone who is used to "think in C" will probably have a hard time to
understand a Haskell program.
Fortunately, almost any loop can be written as a recursive function. So
if you understand recursion and functions and like them more than
loops, try it out.

 

[Richard G. Riley]

Yes, I can vaguely remember doing such things about 25 or 30 years
ago. I outgrew it. I find a sound design and functional breakdown
works much better.

Do you write standalone SW that only you maintain?

I find it incredulous that as a programmer, a debugger isnt a very
important tool on your list.

Noone is suggesting that good design and functionaly breakdown are not
important. What is indisputable though is that a debugger provides a
programmer with an easy, flexible way to perform run time checks and
manipulation of his code. ESPECIALLY when adding or modifying a legacy
system. Frequently you may need to call a poorly document external
function and need to bounds check it to be sure you can handle the
data and that it doesnt fall over with your "perfectly sound" input
data.

 

[David Resnick]

We must come from different schools of thought. I and every programmer
I have ever worked with routinely step through code alone or with a
colleague to check boundary conditions, memory initialisations etc.

I and the programmers I work with do not. What you describe is a
inefficient procedure seems to me. For the cases you mention,
running a thorough regression suite together with tools that analyze
correctness of memory access seems more efficient. For example,
on the project I work on we have an automated run that runs our
(many hundreds) of regression tests under Valgrind and a separate
memory leak checker every weekend.

I regularly use a debugger for analyzing cores. I occasionally
use it for stepping through code to investigate a specific bug,
but I don't use it or need it for code development. We do have
lots of "printfs" (via our configurable logging facility) that is
generally all I need to debug problems. Which is actually more
useful, because while we can ask customers to turn up the
logging, we usually can't and don't want to ask to step through
stuff in the field on their machines.

-David

 

[Richard G. Riley]

I and the programmers I work with do not. What you describe is a
inefficient procedure seems to me. For the cases you mention,
running a thorough regression suite together with tools that analyze
correctness of memory access seems more efficient. For example,

For certain large projects yes.

on the project I work on we have an automated run that runs our
(many hundreds) of regression tests under Valgrind and a separate
memory leak checker every weekend.

Again, very useful. And in no way am I suggesting that these
auotmation tools should not be used.

I regularly use a debugger for analyzing cores. I occasionally
use it for stepping through code to investigate a specific bug,
but I don't use it or need it for code development. We do have
lots of "printfs" (via our configurable logging facility) that is
generally all I need to debug problems. Which is actually more

Fine. but printfs dont allow you to tweak parameters, pointers etc to
check certain things at the point of execution. I find that a very
useful ability and it is, of course, why such facilities exist.

useful, because while we can ask customers to turn up the
logging, we usually can't and don't want to ask to step through
stuff in the field on their machines.

Logging is a different issue as was raised in an earlier post and
certainly has its place in analysing runtime errors or
inefficiencies. There is no argument from me on that.

 

[David Resnick]

Do you write standalone SW that only you maintain?

I find it incredulous that as a programmer, a debugger isnt a very
important tool on your list.

Noone is suggesting that good design and functionaly breakdown are not
important. What is indisputable though is that a debugger provides a
programmer with an easy, flexible way to perform run time checks and
manipulation of his code. ESPECIALLY when adding or modifying a legacy
system. Frequently you may need to call a poorly document external
function and need to bounds check it to be sure you can handle the
data and that it doesnt fall over with your "perfectly sound" input
data.

"As a personal choice, we tend not to use debuggers beyond
getting a stack trace or the value of a variable or two. One
reason is that it is easy to get lostin detals of complicated
data structures and control flow; we find stepping through a
program less productive than thinking harder and adding
output statements and self-checking code at critical places."

Written by those idiots Brian Kernighan and Rob Pike, in the
ill-regarded "The Practice of Programming", section 5.1, Debuggers.
(yes, "idiots" and "ill-regarded" is sarcasm).

That doesn't mean you are entirely wrong. Heck, what do those
guys know that you don't? What it does suggest is that some
respected programmers think that Chuck's approach is perfectly
reasonable. It doesn't mean that you are wrong -- they point out
later in the section that debuggers can be of enormous value.
The perl saying that There's More Than One Way To Do It applies
to code development as well But don't be so sure you have
found the ONE TRUE WAY.

-David

 

[Richard G. Riley]

"As a personal choice, we tend not to use debuggers beyond
getting a stack trace or the value of a variable or two. One
reason is that it is easy to get lostin detals of complicated
data structures and control flow; we find stepping through a
program less productive than thinking harder and adding
output statements and self-checking code at critical places."

Written by those idiots Brian Kernighan and Rob Pike, in the
ill-regarded "The Practice of Programming", section 5.1, Debuggers.
(yes, "idiots" and "ill-regarded" is sarcasm).

And in certain conditions I agree completely. But I do use debuggers
for those stack traces and those variables or two. A lot : personal
choice? Possibly, but I have also find it widespread and good practice
especially when modifying other peoples code.

That doesn't mean you are entirely wrong. Heck, what do those
guys know that you don't? What it does suggest is that some
respected programmers think that Chuck's approach is perfectly
reasonable. It doesn't mean that you are wrong -- they point out

It can never be wrong to aim for bug free code. My stance is simply
that a debugger is, for some, an invaluable tool in acheiving that. I
like to see the data flowing so to speak : it makes me warm and
cosy. Maybe its because I'm not as good a programmer as messrs K & P.

later in the section that debuggers can be of enormous value.
The perl saying that There's More Than One Way To Do It applies
to code development as well But don't be so sure you have
found the ONE TRUE WAY.

I didnt. But submitting code that modifies existing systems without
giving it a once over strikes me as incredibly naive : but thats me.

 

[August Karlstrom]

There are also, AFAIK, two major schools of thought. You obviously
belong to one that believes debuggers are panacea. The other one (and I
count myself in there) believes that if you have to use the debugger
you have failed to understand the problem/code at hand (but it does
have it's use in extreme cases). Obviously, these are the extremes, and
all shades in between exist as well.

This made me think of a quote by E.W. Dijkstra:

"[Poor programmers] derive their intellectual excitement from not
quite knowing what they are doing and prefer to be thrilled by the
marvel of the human mind (in particular their own ones)."


August

 

[Richard G. Riley]

There are also, AFAIK, two major schools of thought. You obviously
belong to one that believes debuggers are panacea. The other one (and I
count myself in there) believes that if you have to use the debugger
you have failed to understand the problem/code at hand (but it does
have it's use in extreme cases). Obviously, these are the extremes, and
all shades in between exist as well.

This made me think of a quote by E.W. Dijkstra:

"[Poor programmers] derive their intellectual excitement from not
quite knowing what they are doing and prefer to be thrilled by the
marvel of the human mind (in particular their own ones)."


August

There is another one from Bertrand Russell:

"The trouble with the world is that the stupid are cocksure and the
intelligent full of doubt."

 

[Mark McIntyre]

I did not ignore that at all. I simply didnt address it :

The point is, you assumed CBF was joking or idiotic because in his
programming env, debuggers are useless or unavailable. In other words,
based on your own limited experience, you extrapolated to the larger
world of programming.

I am astonished. In many years of programming in multiple languages on
multiple platforms I have never heard this school of thought.

Your experience is limited, no shame in admitting that. I also have
zero experience of embedded devices, the closest I ever got was
programming for PalmIII and yes, for that there was no debugger
either, you wrote the code and tested on an emulator.

Any professional programmer who doesnt make use of such facilities is
a very special person.

Or working in a different environment to the one youre used to.
Mark McIntyre

 

[Mark McIntyre]

As I mentioned before a debugger is not just for finding bugs when
they are there. It is used as a vital TESTING tool.

Absolutely not. A debugger is NOT a testing tool, and in my opinion
someone who considers it such is quite foolish.
Mark McIntyre

 

[August Karlstrom]

There is another one from Bertrand Russell:

"The trouble with the world is that the stupid are cocksure and the
intelligent full of doubt."

That's a really good one.


August

 

[Richard G. Riley]

That's a really good one.


August

Heh, and ties in nicely with your .sig :-;

 

[Ben Pfaff]

I find it incredulous that as a programmer, a debugger isnt a very
important tool on your list.

It's not very high up on my list, either. I use printf() and
deep thought more often useful. I find stack traces useful
sometimes, but I can get those without a debugger. I also find a
debugger useful for viewing core dumps.

It's not as though I never do "low-level" programming either.
One of my projects, for example, is an entire (educational)
operating system. In developing that, I don't think I've used a
debugger more than once or twice (and I do have one that works
with it).

 

[Michael Mair]

Connecting to external processes is more rare, I grant you.


lets not get stuck on connecting to remote processes : lets keep it to
using the debugger to test and check new code.

This is very nice for limited amounts of possible input.
But in this case, even simple unit test schemes in combination
with logging suffice.

[This is different, as far as I can tell, from Chris Hill's description
of automated testing using ICEs etc.]

I *always* use a debugger to run through any meaningful critical
code. It enables me to cast an eye over memory, stacks, locals etc. It
is an added safety barrier beyond my own smug ability to write error
free code

Well, I don't know what you're doing; I've just never been in a situation
where this would be helpful. I'm under no illusions about my ability to
write error-free code, it's just that using a debugger doesn't give me
value for money.

We must come from different schools of thought. I and every programmer
I have ever worked with routinely step through code alone or with a
colleague to check boundary conditions, memory initialisations etc. It
is a bedrock of any development I have done. Using break expressions
means I can put in wierd and wonderful parameters and have the
debugger break when a function is suddenly passed something it doesnt
know how to deal with. We are, after all, fallible.

Every serious project with >= 0.5 MLoC I was ever involved in
had its own resource management to track down certain kinds of
errors.
In addition, every single complex feature can be switched off
and internal states and debug indices can be made visible in
the output. Without, debugging would be sheer madness.
Only exception: Paranoia checks with debug mode "asserts".
Unit tests should suffice to feed all kind of "weird and
wonderful" parameters to a module. Regression tests make the
whole thing "round" -- customers and other colleagues tend to
find things one could not imagine when stepping through in the
debugger.

The trace and logging outputs are just builtin "printf()
debugging". When working with huge amounts of data, this may
be the only way to get a first idea what is happening. Without
this idea, you typically don't know what is going wrong, let
alone where.

What you describe sounds perfectly sensible - but I wouldn't describe
it as "using a debugger"; I think this is the disconnect.

[I don't know if I'd call the tools you mention "debuggers", either, but
it's too late to know for sure whether I wouldn't have /before/ this
discussion.]

Debugger. Eclipse "debugger". gdb. All debuggers.

debuggers (and why is the Eclipse debugger awarded scare-quotes?) ...

All code development tools.

... not (necessaily) debuggers: there's a difference here.

Debugging is part of development in my world. maybe we are talking
nomenclature differences here?

Mmmh. I don't know:

- Feature Specification and System Design
<-> Product Test based on the Spec, developed at the same time
by someone who is not the author of the Spec.
- One to several levels of component specifications and design
documents
<-> Automated Developer Tests, external and internal.
- Regular Automated Regression Tests incorporating Product and
Developer Tests as well as a large base of simple and complex
input
- Tracking system to track all requirements and limitations
through the different levels.
- Source control and configuration management.
During Specification and Design Phases: Several reviewers.
Occasional Code Reviews.

Sources of Bugs:
1) "Holes" in the design or specification documents. Most of
the time caught by the test specification process.
2) Implementation errors. Usually caught by the developer
tests.
Debugging: Mostly necessary in legacy code written under time
pressure or circumventing such a process.

For smaller projects: An adapted version of the above.

Such as? An initial use of a debugger to monitor a programs progress
can show up lots of issues as well as facilitating routines boundary
tests. It just makes plain sense.

Design better test drivers and frameworks. It pays.


Cheers
Michael

 

[Richard G. Riley]

It's not very high up on my list, either. I use printf() and
deep thought more often useful. I find stack traces useful

Fair enough. Personally I liek to use the debugger interactively to
tweak parameters etc as I said in another post. Especially when
linking/calling legacy system code.

sometimes, but I can get those without a debugger. I also find a
debugger useful for viewing core dumps.

Not something I'm overly familiar with.

It's not as though I never do "low-level" programming either.
One of my projects, for example, is an entire (educational)
operating system. In developing that, I don't think I've used a
debugger more than once or twice (and I do have one that works
with it).

I'm impressed. I dont think I could : it has become part of my
development process.