NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/54050: malloc_usable_size() is provided on recent NetBSD-current, however malloc.h has no prototype
The following reply was made to PR lib/54050; it has been noted by GNATS.
From: Kamil Rytarowski <n54%gmx.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc:
Subject: Re: lib/54050: malloc_usable_size() is provided on recent
NetBSD-current, however malloc.h has no prototype
Date: Tue, 12 Mar 2019 19:05:09 +0100
On 12.03.2019 14:21, Christos Zoulas wrote:
> On Mar 12, 12:45pm, martin%duskware.de@localhost (Martin Husemann) wrote:
> -- Subject: Re: lib/54050: malloc_usable_size() is provided on recent NetBSD-
>
> | I strongly agree with Joerg here: it should not be part of libc.
>
> I agree. I will move the extra symbols to -ljemalloc. We should not
> be binding libc with a malloc implementation.
>
> | Most software abuses this interface (c.f. firefox about:memmory) and
> | anything that really needs more than the C standard should use its own
> | malloc library that provides whatever it needs without tying our libc
> | to that particular malloc implementation.
> |
> | I have no problem with us proivding a libjemalloc.so.* from the same
> | source we build the intree libc stuff and exposing the interface there,
> | but we may stop providing that shared lib in future releases.
>
> Will do (expose the interface there).
>
> christos
>
I will be happy to pick -ljemalloc for the additional functionality.
Maintaining it partially externally has obvious benefits of jemalloc
major library version bump without issues.
On the other hand we will bind malloc.h with jemalloc.. should it be
namespaced to jemalloc/malloc.h or jemalloc.h?
Home |
Main Index |
Thread Index |
Old Index