Date: Tue, 8 Oct 2013 13:05:18 -0500 From: Eric van Gyzen <eric_van_gyzen@dell.com> To: freebsd-net@freebsd.org Cc: Eric van Gyzen <eric@vangyzen.net> Subject: Re: sys/net/radix.h: #define Free(p) for user-land Message-ID: <5254495E.3050206@dell.com> In-Reply-To: <52541ABF.70101@dell.com> References: <5252D7F7.3030709@dell.com> <20131008141504.GA22563@FreeBSD.org> <52541ABF.70101@dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--------------050603050800010005040000
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
On 10/08/2013 09:46, Eric van Gyzen wrote:
> On 10/08/2013 09:15, Gleb Smirnoff wrote:
>> On Mon, Oct 07, 2013 at 10:49:11AM -0500, Eric van Gyzen wrote:
>> E> The user-land definition of the Free() macro in sys/net/radix.h is
>> E> rather inconvenient. I work on a large C++ code-base, where several
>> E> classes define Free() functions. This header file gets indirectly
>> E> included in a few modules (via nested #includes), so we have to #undef
>> E> Free to work around this macro definition.
>> E>
>> E> Ideally, radix.h would define a more unique name, such as R_Free(). If
>> E> I were using a C code-base, you could say the same about my code, but
>> E> it's C++, and Free() is already well qualified by classes and/or namespaces.
>> E>
>> E> Is this Free() macro considered a well-defined, widely known, and
>> E> therefore mandatory part of the API, or could it be renamed to something
>> E> more unique? Alternatively, could it be changed to an inline function
>> E> definition, so as not to conflict with declarations in other
>> E> namespaces? If any of these is possible, I'll gladly provide the
>> E> blindingly trivial patch, although I don't have a commit bit.
>> E>
>> E> Finding in-tree consumers of this macro is difficult, due to its generic
>> E> name. Its counterparts--R_Malloc and R_Zalloc--only appear in
>> E> sys/net/{radix,route,rtsock}.c (on head). The recent ipfilter update
>> E> removed the only [potential] in-tree user-land consumer.
>>
>> The easiest way to find consumers would be to build test the trivial patch :)
> Gleb,
>
> So true. :) Before I bothered, I just wanted to ask if a change was
> impractical due to API commitments with several known out-of-tree
> consumers. Hearing no such replies, I'll test a patch.
I simply renamed Free to R_Free, and buildworld succeeded. I built head
r256133 on amd64 with no make.conf or src.conf.
So, there are [probably] no in-tree consumers. The question then
becomes, do we need these user-land definitions at all?
Eric
--------------050603050800010005040000
Content-Type: text/plain; charset="ISO-8859-1"; name="radix.h.Free.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="radix.h.Free.patch"
diff --git a/sys/net/radix.h b/sys/net/radix.h
index 5bacaa3..1c8d654 100644
--- a/sys/net/radix.h
+++ b/sys/net/radix.h
@@ -141,7 +141,7 @@ struct radix_node_head {
#ifndef _KERNEL
#define R_Malloc(p, t, n) (p = (t) malloc((unsigned int)(n)))
#define R_Zalloc(p, t, n) (p = (t) calloc(1,(unsigned int)(n)))
-#define Free(p) free((char *)p);
+#define R_Free(p) free((char *)p);
#else
#define R_Malloc(p, t, n) (p = (t) malloc((unsigned long)(n), M_RTABLE, M_NOWAIT))
#define R_Zalloc(p, t, n) (p = (t) malloc((unsigned long)(n), M_RTABLE, M_NOWAIT | M_ZERO))
--------------050603050800010005040000--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5254495E.3050206>