Date: Tue, 8 Oct 2013 09:46:23 -0500 From: Eric van Gyzen <eric_van_gyzen@dell.com> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: freebsd-net@freebsd.org, Eric van Gyzen <eric@vangyzen.net> Subject: Re: sys/net/radix.h: #define Free(p) for user-land Message-ID: <52541ABF.70101@dell.com> In-Reply-To: <20131008141504.GA22563@FreeBSD.org> References: <5252D7F7.3030709@dell.com> <20131008141504.GA22563@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52541ABF.70101>