Time to svn rm include/malloc.h

[Jan Beich]

Konstantin Belousov <kostikbel at gmail.com> writes:

> On Tue, Mar 31, 2020 at 03:48:54PM -0600, Warner Losh wrote:
>
>> On Tue, Mar 31, 2020 at 3:03 PM Konstantin Belousov <kostikbel at gmail.com>
>> wrote:
>> 
>> > On Tue, Mar 31, 2020 at 04:01:23PM -0400, Steve Wills wrote:
>> > > Yeah, a lot of ports have things like:
>> > >
>> > > sed -e 's/malloc.h/stdlib.h/' *.[ch]
>> > >
>> > > because they have autotools that check for malloc.h existence and
>> > include it
>> > > if it exists, so you end up with things like:
>> > >
>> > > ...
>> > > #include <stdlib.h>
>> > > ...
>> > > #if HAVE_MALLOC_H
>> > > #include <stdlib.h>
>> > > #endif
>> > > ...
>> > >
>> > > which ends up harmless, but sub-optimal.
>> > >
>> > So wouldn't it be more useful to remove warning and either include
>> > stdlib.h or provide some parts of malloc-related defines, esp. the
>> > non-portable bits from jemalloc ?
>> >
>> 
>> We've provided an error for the past 20 years. And a warning for the last
>> 24 years. Nobody is usefully using it today. In fact, it is getting in the
>> way, which is why we should just remove it entirely.
> The file is not useful as provided by us today, sure.  But other OSes,
> namely LInux, do use it for allocator extensions features, and newer
> Linux-only software tends to include it unconditionally.

Maybe rename <malloc_np.h> to <malloc.h>. Other BSDs don't have
<malloc_np.h> while GNU libc defines malloc_usable_size in <malloc.h>.
malloc_usable_size is quite popular e.g., used by Firefox, sqlite3, etc.