Debugging memory leaks

[Richard]

Hello. Even if no one cares, I wanted to let the people who gave me
positive inputs know that I changed my code according to their good
suggestions.
I was also wondering why the few times I asked something in clc (about
reentrant/thread-safe functions) everybody told me that it was not a
*standard c* related question, while this time quite everybody told me
to use *implementation defined* solutions. Funny! Probably I should
swap my questions somehow, next time.

Because there is a small clique of noisy regulars who want to limit. You
are with them or against the. See the Soduku thread as a great example
of regs purposely misunderstanding basic scope issues to win points. All
of a sudden Bwian is allowed to not be specific and everyone understands
his unwritten meaning and in addition we have the meaning of extern
being redefined. You could not make it up.

 

[Antoninus Twink]

The only useful C answer to the thread-safe issue was to re-direct you
to forums more appropriate forum for such discussions, since the C
standard doesn't say anthing about threads.

The next version of the C++ standard will say a great deal about
threads.

If the C standard were to follow its lead, then by the "regulars"' own
criteria questions about threads would suddenly become "on topic" here,
which just goes to show how utterly nonsensical their position is.

 

[Ian Collins]

Because there is a small clique of noisy regulars who want to limit. You
are with them or against the. See the Soduku thread as a great example
of regs purposely misunderstanding basic scope issues to win points. All
of a sudden Bwian is allowed to not be specific and everyone understands
his unwritten meaning and in addition we have the meaning of extern
being redefined. You could not make it up.

Yes, do see that thread. It's a classic example of "Richard" making a
complete tit of himself.

 

[CBFalconer]

.... snip ...

I have a bunch of malloc'ing code that I suspect has a memory-
management bug in it somewhere. Wouldn't it be nice if I could
just insert a #include at the top that pulls in some debugging
wrappers without having to change anything else in the code?

Try using DJGPP (see delorie.com) and installing nmalloc for it,
which has a comprehensive debugging package. See:

<http://cbfalconer.home.att.net/download/nmalloc.zip>

or you can try adapting the package to your system. The
non-standardisms are pretty common, but not all systems have a sbrk
call available.

 

[Keith Thompson]

The next version of the C++ standard will say a great deal about
threads.

If the C standard were to follow its lead, then by the "regulars"' own
criteria questions about threads would suddenly become "on topic" here,
Yes.

which just goes to show how utterly nonsensical their position is.

No.

 

[Chris Dollin]

The next version of the C++ standard will say a great deal about
threads.

If the C standard were to follow its lead, then by the "regulars"' own
criteria questions about threads would suddenly become "on topic" here,

Of course.

which just goes to show how utterly nonsensical their position is.

"nonsensical" isn't the right spelling for "sensible", although I can
see how one could confuse them.

 

[CBFalconer]

Of course.


"nonsensical" isn't the right spelling for "sensible", although I
can see how one could confuse them.

Which word does not apply to any such C language inclusion. There
is still no mention of threads in the proposed draft of the next
system, and even if it was present it should be shouted down. C
operates in a simple environment, especially in embedded systems,
and nothing that bars that should be proposed. Note that C++ is
very definitely not C.

 

[Flash Gordon]

CBFalconer wrote, On 17/10/08 15:16:

Which word does not apply to any such C language inclusion. There
is still no mention of threads in the proposed draft of the next
system, and even if it was present it should be shouted down. C
operates in a simple environment, especially in embedded systems,
and nothing that bars that should be proposed. Note that C++ is
very definitely not C.

I believe that there is talk of adding some threading support to the
next C standard and I don't see this as a problem for embedded systems.
The solution is simple and already in use, just as with the bulk of the
standard C library you make it only required for hosted implementations.

 

[lawrence.jones]

"When the facts change, I change my mind. What do you do, sir?" - John
Maynard Keynes.

Most people base their facts on their opinions, rather than the other
way around as logic would suggest.

 

[lawrence.jones]

Which word does not apply to any such C language inclusion. There
is still no mention of threads in the proposed draft of the next
system, and even if it was present it should be shouted down. C
operates in a simple environment, especially in embedded systems,
and nothing that bars that should be proposed.

The current draft is the *very first* draft and contains very little new
material. I can almost guarantee that threads will be prominently
mentioned before the process is complete. Threads and C have been
tightly linked for quite some time: OS kernels, device drivers, and
especially embedded systems are all frequently written in C and
frequently have to deal with multiple threads. Even the current C
standard alludes to threads in the guise of signal handlers. I don't
expect threads to be required, but they need to be discussed so that
people know how to write code that will run reliably when they are
present.

 

[Martin Ambuhl]

Most people base their facts on their opinions, rather than the other
way around as logic would suggest.

As much as we might like it to be otherwise, uninterpreted facts are
rarely a sufficient foundation for an opinion. We may strive to make
our 'opinions' (itself a loaded word used to discredit others' thoughts)
conform to an incontestable external reality, but we know it is
ultimately an impossible task.

 

[user923005]

Most people base their facts on their opinions, rather than the other
way around as logic would suggest.  

I am reminded of this:
http://plato.stanford.edu/entries/bayes-theorem/