Date: Thu, 9 Feb 2023 14:12:35 +0100 From: "Floyd, Paul" <paulf2718@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: CFT: snmalloc as libc malloc Message-ID: <3bacad17-ff6b-8bd3-0559-a70274dcd632@gmail.com> In-Reply-To: <2f3dcda0-5135-290a-2dff-683b2e9fe271@FreeBSD.org> References: <2f3dcda0-5135-290a-2dff-683b2e9fe271@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/02/2023 13:08, David Chisnall wrote: > Hi, > > For the few yearsI've been running locally with snmalloc as the malloc > in libc. Eventually I'd like to propose this for upstreaming but it > needs some wider testing first. > Hi Another allocator to add to my list. I'll give it a go some time, but I have a lot of things on my plate at the moment. I had a quick look. Do you support reallocf? Looking to the fairly short term future, I couldn't see anything for the upcoming C23 sized/aligned free functions. It may be premature as the standard isn't out yet. Recently I did some work on adding a warning for realloc of size 0 to Valgrind (not finished code review yet). I see that you 'free and return NULL' (in the same camp as glibc and ptmalloc). However, jemalloc is in the other camp "maybe free and return a pointer to something" (along with Solaris and musl). That's not really an issue since realloc of 0 is "implementation defined". However, it is slated to become UB in C23. A+ Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bacad17-ff6b-8bd3-0559-a70274dcd632>