From owner-svn-src-all@freebsd.org Tue Aug 18 21:28:28 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 853CF9BB0F9; Tue, 18 Aug 2015 21:28:28 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [204.109.63.53]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67D57A42; Tue, 18 Aug 2015 21:28:28 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.10] (unknown [208.94.83.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 8CBDC286F2; Tue, 18 Aug 2015 14:28:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) 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/... From: Jason Evans In-Reply-To: <20150818211743.GA29760@stack.nl> Date: Tue, 18 Aug 2015 14:28:25 -0700 Cc: Jan Beich , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <790D5607-6662-4817-8CD0-6A435D1F7E49@freebsd.org> References: <201508180021.t7I0LQwE016289@repo.freebsd.org> <20150818211743.GA29760@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.2102) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 21:28:28 -0000 On Aug 18, 2015, at 2:17 PM, Jilles Tjoelker wrote: > On Tue, Aug 18, 2015 at 09:49:44PM +0200, Jan Beich wrote: >> Jason Evans 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 -> In file included from :311: >> In file included from :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 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=