On Aug 18, 2015, at 2:17 PM, Jilles Tjoelker <jil...@stack.nl> wrote: > On Tue, Aug 18, 2015 at 09:49:44PM +0200, Jan Beich wrote: >> Jason Evans <jas...@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); > >> malloc_np.h changes regressing consumers isn't surprising given the lack >> of tests for jemalloc shipped with FreeBSD. > >> $ 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); > > 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. > > 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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
