Page MenuHomeFreeBSD

Make include/malloc.h usable again.
ClosedPublic

Authored by kib on Apr 4 2020, 5:57 PM.

Details

Summary

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.

Fixes bug 155429

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

We either need to remove this file, or make it useful. This does the latter.
NetBSD had just #include <stdlib.h> for years (1994->2019). Last year they effectively added malloc_np.h inline to this file (they don't have the latter). They never did the #error thing.
FreeBSD wanted to remove it because it was non-standard. It almost wasn't in 2.0, but was needed for some old K&R code (aka -traditional mode). We missed our window then.
I suspect that once we imported jemalloc, having this reborn was inevitable.
There's no POSIX or SYS V standard for this file, alas, so it's hard to know if it's standards conforming.
I'd explicitly *NOT* document this in malloc.3. stdlib.h is the proper place to document there.
This needs an exprun to make sure that we don't break anything in ports.

tl;dr: Go for it once exprun come back acceptably.

include/malloc.h
1 ↗(On Diff #70201)

Do we need an actual copyright and/or 'This file is in the public domain' here?

This revision is now accepted and ready to land.Apr 5 2020, 12:49 AM
kib marked an inline comment as done.

Add public domain note.

This revision now requires review to proceed.Apr 5 2020, 8:59 AM
In D24297#534468, @imp wrote:

tl;dr: Go for it once exprun come back acceptably.

I am not sure that exp run provides any value there. Before the patch, #include <malloc.h> aborted the build. So I do not see how any use of it could exist in non-broken port.
Anyway, I will ask portmgr but make a specific note that they should decide themself is it worth spending the resources.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245366

This revision is now accepted and ready to land.Apr 5 2020, 1:48 PM

Looks OK. From my ports/ experience the header is often used when either <stdlib.h> is enough, for memalign or for malloc_usable_size.

Current version doesn't unbreak memalign consumers unless <malloc.h> has something like #define memalign aligned_alloc. If fixed then FreeBSD could take advantage of musl support in various projects. ;)
https://git.musl-libc.org/cgit/musl/tree/include/malloc.h?h=v1.2.0

Note, depending on exp-run results it maybe worth to MFC to /stable branches, allowing ~300 of ports/ to drop malloc.h-related hacks sooner.

Current version doesn't unbreak memalign consumers unless <malloc.h> has something like #define memalign aligned_alloc. If fixed then FreeBSD could take advantage of musl support in various projects. ;)
https://git.musl-libc.org/cgit/musl/tree/include/malloc.h?h=v1.2.0

This is not true implementation of memalign(3). memalign accepts any size argument, while both posix_memalign() and aligned_alloc() require size to be multiple of the alignment.

We can add memalign() later, in fact I already have an experience of converting some project from memalign() to posix_memalign(), including taking care of the size requirement, and indeed adding memalign() would be useful.

Update: D24307 memalign(3).

In D24297#534620, @kib wrote:

Current version doesn't unbreak memalign consumers unless <malloc.h> has something like #define memalign aligned_alloc. If fixed then FreeBSD could take advantage of musl support in various projects. ;)
https://git.musl-libc.org/cgit/musl/tree/include/malloc.h?h=v1.2.0

This is not true implementation of memalign(3). memalign accepts any size argument, while both posix_memalign() and aligned_alloc() require size to be multiple of the alignment.

We can add memalign() later, in fact I already have an experience of converting some project from memalign() to posix_memalign(), including taking care of the size requirement, and indeed adding memalign() would be useful.

Update: D24307 memalign(3).

Agreed. A second commit to implement that would be much much better..

philip added a subscriber: philip.

This is the best solution under the circumstances.

Fine with me.

I wouldn't mind a sentence or two in here about malloc.h's portability, but probably a lost cause.

Avoid pollution of namespace with bool typedef from stdbool.h (for C++).

This revision now requires review to proceed.Apr 23 2020, 9:41 AM
This revision is now accepted and ready to land.Apr 23 2020, 9:54 AM
This revision now requires review to proceed.Apr 26 2020, 9:22 PM
This revision is now accepted and ready to land.Apr 26 2020, 9:42 PM

Remove strings.h.
Don't try to outguess consumers and allow them to define or typedef 'bool' as much as they want.

This revision now requires review to proceed.May 1 2020, 7:17 PM

Like the changes. Thanks for attending to all these pesky details.

This revision is now accepted and ready to land.May 1 2020, 10:14 PM
This revision was automatically updated to reflect the committed changes.