Date:	Tue, 28 Sep 1999 09:37:44 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	GAMMELJL AT SLU DOT EDU
cc:	djgpp AT delorie DOT com
Subject:	Re: problem with malloc.c attn: Michael Bukin and Eli Zaretskii
In-Reply-To:	<01JGGU5V1COM8WW5WR@SLU.EDU>
Message-ID:	<Pine.SUN.3.91.990928093722.17309L-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 27 Sep 1999 GAMMELJL AT SLU DOT EDU wrote:

> There is no doubt that
> an effort is being made to free (or delete) g twice when g is used
> in the last two lines.
>      The problem is: what to do about this.

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?

This is a misunderstanding.  The new malloc does NOT introduce the
bug.  The bug of `free'ing the same memory chunk twice was in the old
malloc as well, but the old version wasn't paying attention because it
didn't care about this particular bug.  The new version does.

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''.

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.

- Raw text -