Bug 155429 - [headers] including malloc.h should not abort compile.
Summary: [headers] including malloc.h should not abort compile.
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-standards (Nobody)
Depends on:
Reported: 2011-03-10 09:30 UTC by Steve Whiteley
Modified: 2020-05-12 18:18 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Steve Whiteley 2011-03-10 09:30:11 UTC
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).


/* $FreeBSD: src/include/malloc.h,v 2010/02/10 00:26:20 kensmith Exp $
#if __STDC__
/* XXX commented to avoid ridiculousness
#error "<malloc.h> has been replaced by <stdlib.h>"
#include <stdlib.h>
How-To-Repeat: test.cc
#include <malloc.h>
int main() { return 0; }
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:46 UTC
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
Comment 2 Jan Beich freebsd_committer 2020-01-12 06:01:46 UTC
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.,


$ cat a.c
#if __has_include(<malloc.h>)
#include <malloc.h>

$ 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
Comment 3 Jan Beich freebsd_committer 2020-01-12 06:32:26 UTC
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. ;)

Comment 4 commit-hook freebsd_committer 2020-05-12 18:18:35 UTC
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

  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

  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