The is not really a bug, just (IMHO) a dumb decision that affects at least up to 7.3. Including <malloc.h> in a c++ source file aborts the compile, with a message informing to include stdlib instead. Well, fine, but some source files written for other OSes may include malloc.h, and are nonportable to FreeBSD simple because of this, i.e., if the malloc.h include is commented out the file compiles fine. The FreeBSD malloc.h should be an empty stub, or at worst emit an info message that malloc.h is not needed in FreeBSD. But to abort the compile? So I have the choice of hunting through a big source like OpenAccess to fix all the malloc.h includes, or hacking the include file itself (my approach, but it always reverts when I update). Fix: /* $FreeBSD: src/include/malloc.h,v 1.5.38.1 2010/02/10 00:26:20 kensmith Exp $ */ #if __STDC__ /* XXX commented to avoid ridiculousness #error "<malloc.h> has been replaced by <stdlib.h>" */ #else #include <stdlib.h> #endif How-To-Repeat: test.cc --------- #include <malloc.h> int main() { return 0; }
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
On Linux/glibc <malloc.h> defines extensions (e.g., memalign, malloc_usable_size, mallinfo) that FreeBSD provides via <malloc_np.h> (e.g., *allocx, malloc_usable_size, mallctl) while similar to upstream jemalloc. If FreeBSD doesn't want to implement glibc extensions like Solaris maybe time to remove <malloc.h> instead e.g., https://github.com/DragonFlyBSD/DragonFlyBSD/commit/02b66c54cac986a0bf93435b8d5ae1b17521515b https://github.com/openbsd/src/commit/d88f57029e5acaaaf028633c7fa15c5d7325c5cc $ cat a.c #if __has_include(<malloc.h>) #include <malloc.h> #endif $ cc -c a.c In file included from a.c:2: /usr/include/malloc.h:3:2: error: "<malloc.h> has been replaced by <stdlib.h>" #error "<malloc.h> has been replaced by <stdlib.h>" ^ 1 error generated. $ rm /usr/include/malloc.h $ cc -c a.c
NetBSD recently exposed jemalloc API via malloc.h but the change is controversial. Compatibility with Linux is limited to malloc_usable_size while compatibility with FreeBSD requires different header. jemalloc API maybe moved to jemalloc.h for compatibility with upstream but if not done before NetBSD 9.0 the move maybe canceled to avoid backward compatibility mess. ;) https://github.com/netbsd/src/commit/fa49bd2033a6 https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=54050
A commit references this bug: Author: kib Date: Tue May 12 18:17:58 UTC 2020 New revision: 360984 URL: https://svnweb.freebsd.org/changeset/base/360984 Log: Make include/malloc.h usable again. Lot of third-party Linux code uses #include <malloc.h>, expecting to find the malloc extensions there. Instead of trying to fight them, accept that attempt to deprecate the header causes more troubles than solves potential portability issues, and provide our jemalloc extensions. PR: 155429 Reviewed by: imp, jhibbits, dab, hselasky, philip, emaste, jilles Exp-run by: antoine (PR 245366) Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D24297 Changes: head/include/malloc.h
<malloc.h> is not a standard header, so it is supposed to be removed. However, because some softwares and operating systems still use it, FreeBSD put it back in 2020. It looks like the problem is now solved!
This was fixed some time ago when jemalloc was added to the tree and the jemalloc specific stuff was added there. It was a dumb decision that took a while to appreciate the full dumbness of....