On Tue, Aug 18, 2015 at 02:28:25PM -0700, Jason Evans wrote: > 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: > >>>>> + - 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). Sorry, I didn't read the code sufficiently thoroughly. The compatibility code looks good, now I see it. > > 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. :( Does that mean that mallocx() and friends will stay for a long time? -- Jilles Tjoelker _______________________________________________ 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"
