[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1e95ce64-828b-1214-a930-1ffaedfa00b8@rasmusvillemoes.dk>
Date: Fri, 23 Mar 2018 09:04:10 +0100
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: Matthew Wilcox <willy@...radead.org>, linux-mm@...ck.org
Cc: Kirill Tkhai <ktkhai@...tuozzo.com>,
Matthew Wilcox <mawilcox@...rosoft.com>,
linux-kernel@...r.kernel.org,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH 3/4] mm: Add free()
On 2018-03-22 20:58, Matthew Wilcox wrote:
> From: Matthew Wilcox <mawilcox@...rosoft.com>
>
> free() can free many different kinds of memory.
I'd be a bit worried about using that name. gcc very much knows about
the C standard's definition of that function, as can be seen on
godbolt.org by compiling
void free(const void *);
void f(void)
{
free((void*)0);
}
with -O2 -Wall -Wextra -c. Anything from 4.6 onwards simply compiles this to
f:
repz retq
And sure, your free() implementation obviously also has that property,
but I'm worried that they might one day decide to warn about the
prototype mismatch (actually, I'm surprised it doesn't warn now, given
that it obviously pretends to know what free() function I'm calling...),
or make some crazy optimization that will break stuff in very subtle ways.
Also, we probably don't want people starting to use free() (or whatever
name is chosen) if they do know the kind of memory they're freeing?
Maybe it should not be advertised that widely (i.e., in kernel.h).
Rasmus
Powered by blists - more mailing lists