Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Oct 2002 21:59:22 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        tlambert2@mindspring.com
Cc:        jake@locore.ca, ben@stuyts.nl, current@FreeBSD.ORG, jroberson@chesapeake.net, rwatson@FreeBSD.ORG, jeff@FreeBSD.ORG, alfred@FreeBSD.ORG
Subject:   Re: [Ugly PATCH] Again: panic kmem_malloc()
Message-ID:  <20021020.215922.59312540.imp@bsdimp.com>
In-Reply-To: <3DB36854.FFEC4E2F@mindspring.com>
References:  <3DB31925.7B70E70@mindspring.com> <20021020.155657.10475080.imp@bsdimp.com> <3DB36854.FFEC4E2F@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <3DB36854.FFEC4E2F@mindspring.com>
            Terry Lambert <tlambert2@mindspring.com> writes:
: "M. Warner Losh" wrote:
: > : > : +     if (sops)
: > : > : +             free(sops, M_SEM);
: > : >
: > : > The kernel free() groks free(NULL, M_FOO), so the if isn't needed.
: > :
: > : Wow.  That's bogus.  It should panic.
: > 
: > It isn't bogus.  free(NULL) is defined to be OK in ansi-c.  The kernel
: > just mirrors that.
: 
: The free(NULL) in ANSI C is to permit invocation of the garbage
: collector; there are very specific semantics involved.  Specifically,
: if you do not call free(NULL), you are *guaranteed* that a malloc()
: followed by a free() followed by a subsequent malloc(), if the size
: of the area allocated by the subsequent malloc() is less than or
: equal to the size of the area freed, *will not fail*.

C99 just says:

section 7.20.3.2:
       [#2] The free function causes the space pointed to by ptr to
       be  deallocated,  that  is,  made  available   for   further
       allocation.   If  ptr  is  a null pointer, no action occurs.
       Otherwise, if the argument does not match a pointer  earlier
       returned  by  the calloc, malloc, or realloc function, or if
       the space has been deallocated by a call to free or realloc,
       the behavior is undefined.

"If ptr is a null poter, no action occurs" doesn't sound like GC to
me.  Like I said, free(NULL) is well defined, and unambiguous, in ansi
c 99.  In fact, I see nothing in the final c99 spec that even comes
close to what you are talking about.  Maybe c89 did that (I'm too lazy
to walk down stairs and find it), but it too is irrelevant as the base
system moves towards c99 compliance.

The rest is bogus too.  free(NULL, M_FOO) is well defined in the
kernel and does the right thing and likely isn't going to change.

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021020.215922.59312540.imp>