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)
The application/software that is being run, is messing up the memory
due to which a subsequent malloc fails.
When the application core is dumped I do not get any backtrace in the
code (although the application is compiled with debug symbols, with -g
option). The only thing I get is the address of the function (and not
the name) where the crash is happening.
Using prints in the code I found that application crashes while calling
malloc. I am linking the standard C library as .so, and thats probably
why there is not backtrace conatining the functions of my application.
There is not enough memory on the board to run gdb. Also due to the
complexity of the scenarios it is not always possible to run gdbserver.
It there a possible way to:
1. Link a debuggable version of stdlib which would put more information
in the core, when it is dumped.
2. Can I enable some asserts or extra information in stdlib which would
tell me if memry is being messed up.
3. Is there a way by which I can map an address to a function of .so
loaded in the memory. Or even if i know that the address belongs t a
perticaular .so
Thanks in advance.
Sep 30 '06
83  3884 
Frederick Gotham wrote:
Keith Thompson posted:
If malloc'ing less than a kilobyte, I wouldn't bother.
That is extraordinarily bad advice.
Of course, it depends on the requirements of the project and so forth, but
there are many circumstances in which I'd just assume that malloc succeeds.
Do you do this on code that others use and count on, or just personal
toy programs?
If you do this on code that others use and count on, then I think
poorly of your judgement and moreover of the abilities of those that
review and approve of your code. This is bad practive, and bad advice
to give. small *alloc calls can and do fail, and dealing with the
failure (even if by just an error message and exit) at the point of
failure is really the thing to do in basically all serious projects.
If you think the opinions of the posters of the board are without
weight, how about this from Kernighan and Pike's "The Practice of
Programming", page 14, "...in a real program the return value of
malloc, reallloc, strdup, or any other allocation routine should always
be checked". I suggest reading that book, it has lots of helpful ideas
about developing quality software.
You are currently arguing for this assertion.
Doing B depends on A succeeding. Don't check that A succeeded before
doing B.
Sounds good, no?
-David
Richard Heathfield posted:
>Of course, it depends on the requirements of the project and so forth, but
there are many circumstances in which I'd just assume that malloc
succeeds.
It's still a stupid assumption, no matter how many times you make it.
(1) Let's say we're running our program.
(2) Let's say we want to allocate 8 bytes.
(3) We call malloc.
(4) It fails.
(5) We must save our user's data and exit the program.
(6) But we must allocate 74 kilobytes in order to save the user's data.
The point I'm making is that it depends on the amount of memory you're trying
to allocate. If you're trying to allocated 6.7 MB, then by all means, take
precautions and preserve the user's data. If you're trying to allocate 13
bytes... well... abandon ship.
>Here's an example of where I'd be wreckless with malloc:
We have no shortage of examples of stupid code.
You cannot assert that the code is stupid unless you know the details of the
project. If the failure of the invocation of "TruncateAndToUppercase" leads
to an irreperable situation, then it might be quite pertinent to exit.
Why add to the mess? And your code is far from wreckless. Spelling
flames for the sake of it are lame, but the difference in meaning
between "reckless" and "wreckless" is significant.
Forgive my ignorance, but allow me a minute's recess to visit
dictionary.com...
I should have written "reckless" rather than "wreckless".
--
Frederick Gotham
Frederick Gotham said:
Richard Heathfield posted:
>>Of course, it depends on the requirements of the project and so forth,
but there are many circumstances in which I'd just assume that malloc
succeeds.
It's still a stupid assumption, no matter how many times you make it.
(1) Let's say we're running our program.
(2) Let's say we want to allocate 8 bytes.
(3) We call malloc.
(4) It fails.
You'll never know this unless you check, of course. And that's why you have
to check. So That You Know.
(5) We must save our user's data and exit the program.
(6) But we must allocate 74 kilobytes in order to save the user's data.
Fine, so you allocate an emergency reserve at the beginning of the program,
to cover your needs (and you try to find a smarter way to preserve the
data, if possible - one that doesn't need so much data). I've been
explaining this for years, to anyone who'll listen. Few do. The cliffs look
so inviting, and the sea down there is so pretty...
The point I'm making is that it depends on the amount of memory you're
trying to allocate.
No, it doesn't. That's ludicrous. What it depends on is whether you want
your program to work robustly. The kind of attitude you are espousing here
is typical amongst a great many "commercial" programmers, and it's one
reason why a great many "commercial" programs are a load of rubbish.
If you're trying to allocated 6.7 MB, then by all
means, take precautions and preserve the user's data. If you're trying to
allocate 13 bytes... well... abandon ship.
So you are claiming that the user's data is less important if you're only
trying to allocate a small amount of memory? Where's the logic in that?
That's just ridiculous! What if your word processor behaved that way? You'd
be furious, and rightly so.
>>Here's an example of where I'd be wreckless with malloc:
We have no shortage of examples of stupid code.
You cannot assert that the code is stupid unless you know the details of
the project.
Yes, I can. It was evident from looking at the code that it was stupid. Even
the author wasn't sure it was correctly written. And of course there is my
rule of thumb: "never trust the code of anyone too stupid to check malloc,
too boorish to apologise for their libels, or both".
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield posted:
>You cannot assert that the code is stupid unless you know the details
of the project.
Yes, I can. It was evident from looking at the code that it was stupid.
Even the author wasn't sure it was correctly written.
You have convinced me. My main peeve against checking malloc's of small
quantities of memory is that it's tedious, and so I think "ExitiveMalloc"
would relieve a bit of stress, not to mention reduce the signal-to-noise
ratio of the code (who wants to read countless lines of error-checking?).
Taking your advice on board though with regard to pre-allocating some reserve
memory in case of emergency, I've cooked up the following. It's a quick
sample of a program which holds important user data in memory -- data which
must be preserved even when the program fails. I think the ExitiveMalloc
works quite well.
---------- FILE BEGIN: exitmal.h ----------
#include <stddef.h>
void *ExitiveMalloc(size_t);
---------- FILE END: exitmal.h ----------
---------- FILE BEGIN: exitmal.c ----------
#include <stddef.h>
#include <stdlib.h>
void *ExitiveMalloc(size_t const size)
{
void *const p = malloc(size);
if(!p) exit(EXIT_FAILURE);
return p;
}
---------- FILE END: exitmal.c ----------
---------- FILE BEGIN: core.c ----------
#include <stdlib.h>
#include "exitmal.h"
void *mem_needed_for_saving;
int backup_required = 0;
void SetupBackupSystem(void)
{
void InitiateEmergencyBackupSequence(void);
mem_needed_for_saving = ExitiveMalloc(98304U);
atexit(InitiateEmergencyBackupSequence);
}
void InitiateEmergencyBackupSequence(void)
{
if(backup_required)
{
/* Use pre-allocated memory to facilitate in saving */
}
}
int main(void)
{
SetupBackupSystem();
/* Let's pretend that this is a circuit schematic package,
and that the user is working on a document. */
/* Now let's say that TruncateAndToUppercase is called, and
that it fails to allocate 23 bytes. TruncateAndToUppercase
contains a call to ExitiveMalloc, and so "exit" is called
upon the allocation failure. */
return 0;
}
---------- FILE END: core.c ----------
If any function in the program invokes ExitiveMalloc, we still preserve our
user's precious data. What do you think?
--
Frederick Gotham
jacob navia <ja***@jacob.remcomp.frwrites:
He is running linux, then I assume memory protection!
Who cares about each possible CPU in the planet?
He is in a certain situation, and give specific advice to THAT
situation!
<OTAnd even in that specific situation, it's bad advice. There's no
guarantee that a pointer with a random value will point to memory that
that process does not have access to. Memory protection only works
when you attempt to scribble on memory belonging to another process,
not when you attempt to scribble on memory belonging to your own
process. </OT>
This is why you're consistently admonished to keep your posts on the
topic of Standard C.
Charlton
Frederick Gotham wrote:
Richard Heathfield posted:
>>You cannot assert that the code is stupid unless you know the details
of the project.
Yes, I can. It was evident from looking at the code that it was stupid.
Even the author wasn't sure it was correctly written.
You have convinced me. My main peeve against checking malloc's of small
quantities of memory is that it's tedious, and so I think "ExitiveMalloc"
would relieve a bit of stress, not to mention reduce the signal-to-noise
ratio of the code (who wants to read countless lines of error-checking?).
I would like to read the countless lines of error checking
because I had bad experience with other people's code when they
don't do it and I have to write it myself to find out the problem
with buggy code that has too many failure points that are unchecked.
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Frederick Gotham said:
What do you think?
I think you owe Keith Thompson an apology for behaving abusively towards
him.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
In article <87************@mithril.chromatico.net>,
Charlton Wilbur <cw*****@mithril.chromatico.netwrote:
><OTAnd even in that specific situation, it's bad advice. There's no
guarantee that a pointer with a random value will point to memory that
that process does not have access to. Memory protection only works
when you attempt to scribble on memory belonging to another process,
not when you attempt to scribble on memory belonging to your own
process. </OT>
Depends on the system. It isn't uncommon at all for systems to be
able to offer protection against writing to particular pages.
That would protect a process from itself.
For an obvious example of this, think of compilers that put
string literals into non-writable memory.
Per-page memory protection bits that I've heard of on various systems
include: Read, Write, Execute, and Copy-on-Write
On most of the systems, Execute implies Read as well, but on
some apparently it doesn't: those systems can be configured so that
no -explicit- read access to the pages are made.
>This is why you're consistently admonished to keep your posts on the
topic of Standard C.
Unfortunately, your technical correction was itself flawed. And
probably -my- technical correction to your correction has some flaw
as well. It would have been better if Jacob hadn't made the
non-portable assumption, which probably wasn't even completely
portable within the domain of systems ("Linux") he was intending
his advice to apply to.
--
Prototypes are supertypes of their clones. -- maplesoft
Frederick Gotham <fg*******@SPAM.comwrites:
Keith Thompson posted:
>>If malloc'ing less than a kilobyte, I wouldn't bother.
That is extraordinarily bad advice.
Of course, it depends on the requirements of the project and so forth, but
there are many circumstances in which I'd just assume that malloc succeeds.
[snip]
People should of course decide for themselves, but I personally
recommend avoiding any advice offered by Frederick Gotham. Anyone who
(a) advocates failing to check the result of malloc() and (b)
stubbornly refuses to apologize for repeated libel is not to be
trusted.
Frederick: I again call on you to apologize for your earlier insults.
(You know perfectly well what I'm talking about.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Charlton Wilbur wrote:
jacob navia <ja***@jacob.remcomp.frwrites:
>>He is running linux, then I assume memory protection!
Who cares about each possible CPU in the planet?
He is in a certain situation, and give specific advice to THAT
situation!
<OTAnd even in that specific situation, it's bad advice. There's no
guarantee that a pointer with a random value will point to memory that
that process does not have access to. Memory protection only works
when you attempt to scribble on memory belonging to another process,
not when you attempt to scribble on memory belonging to your own
process. </OT>
This is why you're consistently admonished to keep your posts on the
topic of Standard C.
Charlton
According to the standard, malloc can return either NULL or
a VALID pointer so your argumentation makes no sense.
Malloc can never return an invalid pointer (at least according
to the specs).
You are confusing. I am speaking about not testing the result
of malloc, not using uninitialized variables or whatever!!!
The idea is that in a debug setting, a failed
malloc means that a bad size was passed in. In that case it
is better to leave the program crash right there and see
with the debugger what is happening.
This is one way of debugging software. It is maybe not
the best, and relies on a specific OS characteristics.
On Tue, 03 Oct 2006 10:43:33 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Richard Heathfield wrote:
>will be run. Advice given here about C should be /general/ advice; it
should be good for /any/ hosted implementation (and, if applicable, on
freestanding implementations).
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
Frederick Gotham wrote:
Richard Heathfield posted:
>>You cannot assert that the code is stupid unless you know the
details of the project.
Yes, I can. It was evident from looking at the code that it was
stupid. Even the author wasn't sure it was correctly written.
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:
<news:news.announce.newusers
<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/>
CBFalconer <cb********@yahoo.comwrote:
Frederick Gotham wrote:
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.
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
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.
--
Frederick Gotham ac*********@gmail.com wrote:
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.
The application/software that is being run, is messing up the memory
due to which a subsequent malloc fails.
When the application core is dumped I do not get any backtrace in the
code (although the application is compiled with debug symbols, with -g
option). The only thing I get is the address of the function (and not
the name) where the crash is happening.
Using prints in the code I found that application crashes while calling
malloc. I am linking the standard C library as .so, and thats probably
why there is not backtrace conatining the functions of my application.
There is not enough memory on the board to run gdb. Also due to the
complexity of the scenarios it is not always possible to run gdbserver.
It there a possible way to:
1. Link a debuggable version of stdlib which would put more information
in the core, when it is dumped.
2. Can I enable some asserts or extra information in stdlib which would
tell me if memry is being messed up.
3. Is there a way by which I can map an address to a function of .so
loaded in the memory. Or even if i know that the address belongs t a
perticaular .so
Thanks in advance.
Richard Bos wrote:
CBFalconer <cb********@yahoo.comwrote:
>Frederick Gotham wrote:
>>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.
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:
<news:news.announce.newusers
<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/>
CBFalconer posted:
<With regard to myself>
>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.
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
--
Frederick Gotham
CBFalconer wrote:
>
Richard Bos wrote:
CBFalconer <cb********@yahoo.comwrote:
Frederick Gotham wrote:
>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.
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.
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.
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
In article <45***************@comcast.net>,
Charles Richmond <ri******@plano.netwrote:
....
>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.
Frederick Gotham wrote:
Richard Heathfield posted:
Set indeterminate ('dangling') pointers to NULL.
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.
Richard Heathfield wrote:
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)
Christopher Layne wrote:
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.
Frederick Gotham wrote:
#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.
Old Wolf said:
Richard Heathfield wrote:
>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?
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.
>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)
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
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Old Wolf said:
Frederick Gotham wrote:
<snip>
>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);
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.
<snip>
I, for one, would not hesitate to call this function stupid.
Nevertheless (and whether by accident or design), it taught you something
about assert(). :-)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Old Wolf posted:
Christopher Layne wrote:
>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.
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:
> int const assert_dummy = (assert(!!arg), 0);
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.
> 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).
I'll have to read up on that function.
> while( *p++ = toupper((char unsigned)*p) );
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?
> return (void)assert_dummy, retval;
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.
--
Frederick Gotham
Frederick Gotham wrote:
Old Wolf posted:
.... snip ...
>>
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?
Both Shakespeare and Erle Stanley Gardner used a "Dramatis
Personnae" section. Very handy.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
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... */
}
--
Frederick Gotham
Frederick Gotham <fg*******@SPAM.comwrites:
Old Wolf posted:
>> int const assert_dummy = (assert(!!arg), 0);
Is this supposed to be an improvement on:
assert(arg);
You can't mix statements and declarations in C (within a block).
You can in C99.
>? And what is the '!!' doing?
The argument to "assert" must be of the type, int.
In C99, it merely has to be a scalar expression.
[snip]
>> return (void)assert_dummy, retval;
Huh?
The cast-to-void is intended to suppress a compiler warning regarding non-
usage of a variable.
It may or may not do so, depending on the compiler.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
in 701336 20061015 152559 Frederick Gotham <fg*******@SPAM.comwrote:
>int i; To hold the amount of chickens
It's "number of chickens".
(You'd need a float to hold the amount of chicken ;-) )
Bob Martin wrote:
in 701336 20061015 152559 Frederick Gotham <fg*******@SPAM.comwrote:
>int i; To hold the amount of chickens
It's "number of chickens".
(You'd need a float to hold the amount of chicken ;-) )
No, you need float for ducks.
--
Flash Gordon
Flash Gordon <sp**@flash-gordon.me.ukwrites:
Bob Martin wrote:
>in 701336 20061015 152559 Frederick Gotham <fg*******@SPAM.comwrote:
>>int i; To hold the amount of chickens
It's "number of chickens".
(You'd need a float to hold the amount of chicken ;-) )
No, you need float for ducks.
No, the ducks can float by themselves, so you need a float for the
chickens.
You get down off a duck.
But we should really be talking about C gulls.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Advocated |
last post by:
Hi there, just wondering if anyone uses visual studio 6?
Im having real problems, just with debugging, i could either do with a
really good tutorial, if anyone knows of one, but the main thing...
|
by: ibic |
last post by:
Just curious: is it possible to recursively list all the
directorys/files inside a given directory using standard c i/o library
routines only, which can be re-compiled and run on any os supportes c...
|
by: yinglcs |
last post by:
I am trying to debug a C++ program in GDB on linux.
I want to dump out the content of the "this" object,
Here is what I get:
(gdb) print *this
$2 = {path = <incomplete type>}
My question is...
|
by: David Mathog |
last post by:
One thing that keeps coming up in this forum is that
standard C lacks many functions which are required in
a workstation or server but not possible in an embedded controller.
This results in a...
|
by: fermineutron |
last post by:
Some compilers support __asm{ } statement which allows integration of C
and raw assembly code. A while back I asked a question about such
syntax and was told that __asm is not a part of a C...
| | |
by: phnimx |
last post by:
Hi ,
We have developed a number of plug-in .NET Library Components that we
typically deploy with our various applications by installing them into the
GAC.
Each of the applications contains an...
|
by: J de Boyne Pollard |
last post by:
MThe library functions which are included to allow process
Mlaunch, forking, and termination, imply that it is both
Mpossible and desirable for a process to fork itself. This is
Ma fundamental...
|
by: Jeff |
last post by:
I understand there's socket / recursive calls here, but this is a C
question, really it is:
Here's the code block in question:
#if defined(__GLIBC__)
{
struct hostent hent;
char hbf;...
|
by: fmassei |
last post by:
Hello!
I made a short piece of code that I find very useful for debugging,
and I wanted to ask you if it is correct, somehow acceptable or if I
simply reinvented the wheel.
To deal with some bad...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
