Debugging standard C library routines

[Mark McIntyre]

Who are YOU to tell ME what advice should I give?

He's a regular in CLC, and he's not ordering you to do anything, he;'s
reminding you of the topic in CLC.

By the way who are YOU to contemptuously ignore the topic of the
group, and arrogantly continue to post irrelevant and often incorrect
material? When you have resolve those problems, then you'll have
something to say.

He is running linux, then I assume memory protection!

And you have proof absolute that he's running Linux, will only ever
run Linux, and that his linux, and indeed all linuxes, offer this
memory protection of which you speak

Who cares about each possible CPU in the planet?

Clearly not you, with your small "all the world's an x86" perspective.
Wake up and smell the coffee.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[CBFalconer]

Richard Heathfield posted:


You have convinced me. My main peeve against checking malloc's of .... snip ...

If any function in the program invokes ExitiveMalloc, we still
preserve our user's precious data. What do you think?

I think that I still have not seen any apologies to Richard and
Keith, in the absence of which I tend to ignore you and your
thoughts.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[Richard Bos]

I think that I still have not seen any apologies to Richard and
Keith, in the absence of which I tend to ignore you and your
thoughts.

I think that, while those apologies might indeed be in order, the
repetitive demands for them aren't doing the group any good.

Just killfile him, and knock it off, guys.

Richard

 

[Frederick Gotham]

CBFalconer posted:

I think that I still have not seen any apologies to Richard and
Keith, in the absence of which I tend to ignore you and your
thoughts.

Doesn't make such sense since you took the time to reply. Do me a favour and
killfile me.

 

[Ivanna Pee]

I am working on MontaVista Linux on a PPC board.
The compiler I am using is a gnu cross compiler cross compiler
(ppc-82xx-gcc)

Sounds like an embedded application running on a PPC single board
computer. I've seen this before, where, if I remember correctly I had
to write a custom __init and __sbrk routine to support the dynamic
memory management C library routines.

 

[CBFalconer]

I think that, while those apologies might indeed be in order, the
repetitive demands for them aren't doing the group any good.

Just killfile him, and knock it off, guys.

The problem is that he shows intelligence and promise. All we
really need to do is to correct his faulty upbringing and we could
have a worthwhile netizen.

--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

 

[Frederick Gotham]

CBFalconer posted:

The problem is that he shows intelligence and promise. All we
really need to do is to correct his faulty upbringing and we could
have a worthwhile netizen.

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

 

[Charles Richmond]

The problem is that he shows intelligence and promise. All we
really need to do is to correct his faulty upbringing and we could
have a worthwhile netizen.

How many wives have thought that about the bummy husbands
that they married??? "If he would only quite drinking and
fooling around, he is really a good man."

Few in c.l.c have the time, inclination, or educational
background to spend the years of analysis it would take
to correct psychological flaws in malcontented posters.

The short answer...plonk him.

 

[Kenny McCormack]

Few in c.l.c have the time, inclination, or educational
background to spend the years of analysis it would take
to correct psychological flaws in malcontented posters.

The short answer...plonk him.

The problem with this - and why nobody ever plonks anybody here, despite
claims to the contrary - is that if they did (plonk all the trolls),
they'd have to start preying on each other.

History is replete with examples of this - where a force is created
with the purpose of eradicating some social plague, then when that
plague is eradicated, the force, having now nothing to do, ends up
preying on itself. Generally, once you create a force, it becomes
self-perpetuating.

 

[Old Wolf]

Richard Heathfield posted:


In Debug Mode, maybe. It wastes valuable nanoseconds (if not microseconds)
in Release Mode.

How does it waste nanoseconds in "Release Mode" (whatever that is) ?

If the pointer is subsequently reassigned-to, or not used again before
its lifetime ends, then setting to NULL will be optimised out.

If the pointer is dereferenced instead, then you have undefined
behaviour anyway, so what does a few nanoseconds matter?

Finally, if your pointer is global, then a pox on you.

 

[Old Wolf]

Great example. Well done. If you omit the initialisation, okay, let's say
the compiler issues a warning (despite the fact that it needn't and some
don't). But you know and I know that some people will say "oh, it's only a
warning, it's fine", and they'll be scratching their heads trying to debug
it.

Do people really ignore the warning "use of uninitialized variable",
when trying to debug a piece of code that produces that warning
and is behaving strangely?

Whereas, if you set q to NULL, then it doesn't take a genius to
discover that *start is being set to an obviously silly value (probably
NULL, possibly 1). So the debugging process is very swift after all.

It can be a slow process, when working on an embedded device
where writing to low-numbered addresses causes the thing to crap
itself and take you several minutes to reload everything... (recall
my *dest++ = *src++ bug)

 

[Old Wolf]

I personally despise this C++/"declare on a whim" style. I like to know what
I'm getting into when I read over a function - and a function which has it's
table of contents spread out and buried within individual chapters just
pisses me off more than it helps anything.

Worst analogy of the week.

Why would you possibly care which variables a function uses,
unless you are coding to tight stack requirements?

Further, why would you try and deduce a function's activities by
reading its list of variables? Surely it would be better to read the
comments, or observe the code structure.

 

[Old Wolf]

#include <stddef.h>
#include <stdlib.h>

void *ExitiveMalloc(size_t const size)
{
void *const p = malloc(size);
if(!p) exit(EXIT_FAILURE);
return p;
}

Here's an example of where I'd be wreckless with malloc:

You wouldn't cause any wrecks? Are you sure?

#include <stddef.h>
#include <stdlib.h>
#include <assert.h>
#include <string.h>
#include <ctype.h>

char *const TruncateAndMakeUppercase(char const *const arg,size_t const len)
{
int const assert_dummy = (assert(!!arg), 0);

Is this supposed to be an improvement on:
assert(arg);

? And what is the '!!' doing?

char *const retval=ExitiveMalloc(len+1), *p=retval;

ExitiveMalloc exits if it fails to allocate. So this code is not
reckless with failing to check the return value of malloc.

strncpy(retval,arg,len);

Does not 0-terminate the string in some cases
(so the attempt to iterate over the string would cause
a buffer overflow).

while( *p++ = toupper((char unsigned)*p) );

Undefined behaviour. What if 'p' is incremented before
being evaluated for dereferencign to pass to 'toupper' ?

return (void)assert_dummy, retval;
Huh?

}
You cannot assert that the code is stupid unless you know the details of the
project.

I, for one, would not hesitate to call this function stupid.

 

[Richard Heathfield]

Old Wolf said:

Do people really ignore the warning "use of uninitialized variable",
when trying to debug a piece of code that produces that warning
and is behaving strangely?

I'm sorry, but yes, they do. I'm astounded at the warnings people are
prepared to ignore. I've even seen people try to ignore syntax errors.

It can be a slow process, when working on an embedded device
where writing to low-numbered addresses causes the thing to crap
itself and take you several minutes to reload everything... (recall
my *dest++ = *src++ bug)

I don't see how writing to random addresses would help you speed things up!
But this is Yet Another Advantage of writing portable code - you can catch
such silly bugs on a desktop platform, and only move code to the bitty-box
when you know it stands a fighting chance of being right.

 

[Richard Heathfield]

Old Wolf said:

Frederick Gotham wrote:


Is this supposed to be an improvement on:
assert(arg);

Well, it's obviously a lousy idea, but yes, there's an improvement in
there...

? And what is the '!!' doing?

Making the assertion arg an integer expression rather than a pointer
expression, and thus keeping the behaviour well-defined in C90.

I, for one, would not hesitate to call this function stupid.

Nevertheless (and whether by accident or design), it taught you something
about assert().

 

[Frederick Gotham]

Old Wolf posted:

Worst analogy of the week.

Why would you possibly care which variables a function uses,
unless you are coding to tight stack requirements?

Further, why would you try and deduce a function's activities by
reading its list of variables? Surely it would be better to read the
comments, or observe the code structure.

While we're talking about literature... would you prefer if each character
was described on the first page of the first chapter, or would you prefer if
each consecutive character were introduced to the reader as the plot
develops?

 

[Frederick Gotham]

Old Wolf posted:

Is this supposed to be an improvement on:
assert(arg);

You can't mix statements and declarations in C (within a block).

? And what is the '!!' doing?

The argument to "assert" must be of the type, int.

Does not 0-terminate the string in some cases
(so the attempt to iterate over the string would cause
a buffer overflow).

I'll have to read up on that function.

Undefined behaviour. What if 'p' is incremented before
being evaluated for dereferencign to pass to 'toupper' ?

Are you sure that a sequence point has been violated?

Huh?

The cast-to-void is intended to suppress a compiler warning regarding non-
usage of a variable.

 

[Frederick Gotham]

Old Wolf posted:

If the pointer is subsequently reassigned-to, or not used again before
its lifetime ends, then setting to NULL will be optimised out.

The Standard does not impose such a restriction.

If the pointer is dereferenced instead, then you have undefined
behaviour anyway, so what does a few nanoseconds matter?

Finally, if your pointer is global, then a pox on you.

A pox on your naivety. A programmer who hasn't found a use for a global
pointer is like a grown adult who hasn't found a use for one of the many
tools he was told to avoid as a kid... blow tourches, knives, drills, bleach.

I've been programming long enough to make my own decisions.

 

[CBFalconer]

Old Wolf posted:
.... snip ...

While we're talking about literature... would you prefer if each
character was described on the first page of the first chapter, or
would you prefer if each consecutive character were introduced to
the reader as the plot develops?

Both Shakespeare and Erle Stanley Gardner used a "Dramatis
Personnae" section. Very handy.

 

[Frederick Gotham]

CBFalconer posted:

Both Shakespeare and Erle Stanley Gardner used a "Dramatis
Personnae" section. Very handy.

There's nothing to stop someone doing something like:


void Func()
{
/* This function defines the following local objects:

int i; To hold the amount of chickens
double r; To hold the mean mass of a chicken
*/


/* ... Now define them however you please... */
}