Date: Tue, 18 Aug 2015 14:28:25 -0700 From: Jason Evans <jasone@freebsd.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: Jan Beich <jbeich@FreeBSD.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r286866 - in head: contrib/jemalloc contrib/jemalloc/doc contrib/jemalloc/include/jemalloc contrib/jemalloc/include/jemalloc/internal contrib/jemalloc/src include lib/libc/gen lib/libc/... Message-ID: <790D5607-6662-4817-8CD0-6A435D1F7E49@freebsd.org> In-Reply-To: <20150818211743.GA29760@stack.nl> References: <201508180021.t7I0LQwE016289@repo.freebsd.org> <pp2l-jjsm-wny@FreeBSD.org> <C355793A-7EFE-4E6E-ACBF-5F772F6AC1E7@freebsd.org> <r3n0-74x3-wny@FreeBSD.org> <20150818211743.GA29760@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 18, 2015, at 2:17 PM, Jilles Tjoelker <jilles@stack.nl> wrote: > On Tue, Aug 18, 2015 at 09:49:44PM +0200, Jan Beich wrote: >> Jason Evans <jasone@freebsd.org> writes: >>>>> Index: include/malloc_np.h >> [...] >>>>> +typedef void *(chunk_alloc_t)(void *, size_t, size_t, bool *, = bool *, unsigned); >>>>> +typedef bool (chunk_dalloc_t)(void *, size_t, bool, unsigned); >=20 >> malloc_np.h changes regressing consumers isn't surprising given the = lack >> of tests for jemalloc shipped with FreeBSD. >=20 >> $ cc -include malloc_np.h -c -xc -</dev/null >> In file included from <built-in>:311: >> In file included from <command line>:1: >> /usr/include/malloc_np.h:39:55: error: unknown type name 'bool' >> typedef void *(chunk_alloc_t)(void *, size_t, size_t, bool *, bool = *, unsigned); >> ^ >> /usr/include/malloc_np.h:39:63: error: unknown type name 'bool' >> typedef void *(chunk_alloc_t)(void *, size_t, size_t, bool *, bool = *, unsigned); >=20 > A #include <stdbool.h> will of course fix this, but by using 1, 0 and > _Bool instead of true, false and bool you can make it work without > adding namespace pollution. This might be useful if someone has bool > defined or typedeffed to something else. Note that only the header = files > need to be uglified this way. Cool, I'll make that change to the patch I'm currently testing. >>>>> + - Remove the *allocm() API, which is superseded by the = *allocx() API. >>>> Symbol.map and manpages haven't been updated. >=20 > You can't really remove anything from Symbol.map files, since that > breaks binary compatibility for applications that used the removed > symbols. Such breakage usually crashes the application if and when it > attempts to use a removed symbol. To avoid the breakage, wrappers > invoking the new APIs should be provided; using some special symver > directives, it is possible to prevent linking new applications against > the obsolete symbols. *allocm() compatibility functions are in place, so I think this is = correctly sorted out. Jan also pointed out missing entries for = sdallocx() in a previous email, which I've already committed the fix for = (r286872). > A corollary is that experimental APIs should not be added to = Symbol.map. > It may be better for developers that want to use experimental APIs to > build jemalloc themselves, or to use jemalloc from ports (although = such > a port doesn't seem to exist, currently). Yes, exposing *allocm() was a big mistake. :( Thanks, Jason=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?790D5607-6662-4817-8CD0-6A435D1F7E49>