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 mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-10 09:30 UTC by Steve Whiteley
Modified: 2020-01-12 06:32 UTC (History)
0 users

See Also:


Attachments

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).

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; }
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.,

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
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. ;)

https://github.com/netbsd/src/commit/fa49bd2033a6
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=54050