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/...

[Jason Evans]

On Aug 18, 2015, at 2:17 PM, Jilles Tjoelker <jilles at stack.nl> wrote:
> On Tue, Aug 18, 2015 at 09:49:44PM +0200, Jan Beich wrote:
>> Jason Evans <jasone at 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