From owner-freebsd-hackers  Sun Sep 21 19:58:07 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA04812
          for hackers-outgoing; Sun, 21 Sep 1997 19:58:07 -0700 (PDT)
Received: from kithrup.com (kithrup.com [205.179.156.40])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA04806
          for <hackers@freebsd.org>; Sun, 21 Sep 1997 19:58:04 -0700 (PDT)
Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id TAA27605; Sun, 21 Sep 1997 19:58:03 -0700 (PDT)
Date: Sun, 21 Sep 1997 19:58:03 -0700 (PDT)
From: Sean Eric Fagan <sef@Kithrup.COM>
Message-Id: <199709220258.TAA27605@kithrup.com>
To: tim@ppp6431.on.sympatico.ca
Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?)
Cc: hackers@freebsd.org
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>> 	char *cp = malloc(100);
>> 	if (cp) {
>> 		free(cp);
>> 		cp = malloc(100);
>> 	}
>No, if you want the above code to always result in a non-NULL cp,
>free() cannot ever return the memory back to the OS.

Really?  Would you like to explain that idiotic statement?  Back it up with
some facts, explanations, or justifications?

There is only one situation in which that code fragment can have cp set to
NULL -- when the first malloc() fails.  That is the

	char *cp = malloc(100);

I did not point that out because I thought it was obvious.  And it doesn't
change my position:  if the first malloc() succeeded, then, even if there is
no more space available after that first malloc(), the free() and subsequent
malloc() are required to work.

You can believe whatever you want, but it is contrary to what the intent and
wording of X3J11 came to.

Or so say the seven or eight members of the committee that I've known since
it was first formed.