Mail Archives: djgpp/1999/09/28/11:59:36
Eli Zaretskii (eliz AT is DOT elta DOT co DOT il) wrote:
: You need to fix your code to avoid calling `free' more than once.
: > It is an absurd situation.
: > Other compilers, such as the Watcom C/C++ compiler, and indeed the
: > Delorie port of the gnu compiler with the old malloc.c, have no trouble.
: > Why should the Delorie port of the gnu compiler with the new malloc.c?
??
You run this type of hack on a Un*x box it will send you
crashing and burning with a sigvec or sigbus.
...
: I don't know how do other compilers implement malloc/free, but a buggy
: application code (yours) invokes what's called ``undefined behavior'',
: which in English means ``anything can happen''.
Absolutely, some implementation can use a free list of memory pool
and calling free() twice, will muck up the free list. If you are lucky
it will crash in the free() and it this case it is easy to see, in
the worst case scenario, the memory allocator is corrupted and you have
runaway pointers. Usually the application will crash when you're
doing a demo or a conference, sending bad vibes down your spin ;-)
and your bonus check to oblivion. I know .. I've been there.
: The right way to solve this is to fix your code, not to blame the
: library for misbehaving when you violate the rules of the game.
8-) [laughs] this is normal programmers reflexes, the first thing
is to blame, anything but your code(the ABTC syndrome)
the second is the ubiquitous : "It used to work before !"
--
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!
- Raw text -