Make include/malloc.h usable again.

[kib]

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

[imp]

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

0–4

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

[kib]

Add public domain note.

[kib]

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

[jbeich]

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.

[kib]

In D24297#534619, @jbeich 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).

[imp]

In D24297#534620, @kib wrote:

In D24297#534619, @jbeich 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]

This is the best solution under the circumstances.

[emaste]

Fine with me.

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

[kib]

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

[emaste]

OK

[kib]

One 'bool' was missed.

[kib]

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

[imp]

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