[feature request] add mallinfo support

[feature request] add mallinfo support

[Gonzalo Brito Gadeschi]

[-- Attachment #1: Type: text/plain, Size: 184 bytes --]

That's mostly about it: musl currently does not support mallinfo, described
here:

http://man7.org/linux/man-pages/man3/mallinfo.3.html

Note: I am not subscribed to the mailing list.

[-- Attachment #2: Type: text/html, Size: 289 bytes --]

Re: [feature request] add mallinfo support

[Rich Felker]

On Wed, Jan 17, 2018 at 06:32:02PM +0100, Gonzalo Brito Gadeschi wrote:
> That's mostly about it: musl currently does not support mallinfo, described
> here:
> 
> http://man7.org/linux/man-pages/man3/mallinfo.3.html
> 
> Note: I am not subscribed to the mailing list.

Omission of mallinfo is largely intentional. The API is fundamentally
broken (using type int which cannot represent sizes) and tracking the
information it provides imposes nontrivial costs on the malloc
implementation. It was discussed in the past that a stub/dummy could
be provided, but prevailing opinion seemed to be that it would be
better not to:

http://www.openwall.com/lists/musl/2013/11/09/2

It's probably better that programs trying to use mallinfo fail to
build so that you can identify and fix the problem rather than hiding
it.

Rich

Re: [feature request] add mallinfo support

[Gonzalo Brito Gadeschi]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

Thanks for the quick reply.

> Omission of mallinfo is largely intentional.

Makes sense, it would have saved me some time if this
information would be added to the FAQ. I tried to search
the mailing list (or musl website for a bug tracker) without
any luck.

> The API is fundamentally
broken (using type int which cannot represent sizes) and tracking the
information it provides imposes nontrivial costs on the malloc
implementation.

I agree.

> http://www.openwall.com/lists/musl/2013/11/09/2
I went through the thread and could not find the piece of information
that lead to that opinion (maybe I am just generally bad at mailing lists).

Rich Felker (you :D) argued:

> The main reason I'd want to provide a dummy is if
> there are glibc binaries using it. The range of the counters
> is fairly irrelevant; keeping track of the information is prohibitively
> slow anyway since it would have to be synchronized between
> threads on each call to malloc/free. (glibc does some poor
> hack keeping this info per-arena and summarizing it when
mallinfo is called, I think...)

And Szabolcs Nagy just answered:

> i see

That's all I found there.

FWIW I wouldn't mind if mallinfo on musl
would just return a zeroed mallinfo struct,
because I don't even know if the function is
called at all: I just know that the code won't
compile without those symbols.

Arguably, I can do that workaround myself,
so I'll just do that for now.

Thanks again for the quick reply!
Gonzalo

[-- Attachment #2: Type: text/html, Size: 1773 bytes --]

Re: [feature request] add mallinfo support

[Dmitry Golovin]

> I tried to search the mailing list (or musl website for a bug tracker) without any luck.

There is no bugtracker at the moment. This mailing list kinda acts as one, but having something powerful like Bugzilla or at least GitHub issues may be beneficial for the development.

Regards,
Dmitry

18.01.2018, 13:58, "Gonzalo Brito Gadeschi" <gonzalo.gadeschi@rwth-aachen.de>:
> Thanks for the quick reply.
>
>> Omission of mallinfo is largely intentional.
>
> Makes sense, it would have saved me some time if this
> information would be added to the FAQ. I tried to search
> the mailing list (or musl website for a bug tracker) without
> any luck.
>
>> The API is fundamentally
> broken (using type int which cannot represent sizes) and tracking the
> information it provides imposes nontrivial costs on the malloc
> implementation.
>
> I agree.
>
>> http://www.openwall.com/lists/musl/2013/11/09/2
> I went through the thread and could not find the piece of information
> that lead to that opinion (maybe I am just generally bad at mailing lists).
>
> Rich Felker (you :D) argued:
>
>> The main reason I'd want to provide a dummy is if
>> there are glibc binaries using it. The range of the counters
>> is fairly irrelevant; keeping track of the information is prohibitively
>> slow anyway since it would have to be synchronized between
>> threads on each call to malloc/free. (glibc does some poor
>> hack keeping this info per-arena and summarizing it when
> mallinfo is called, I think...)
>
> And Szabolcs Nagy just answered:
>
>> i see
>
> That's all I found there.
>
> FWIW I wouldn't mind if mallinfo on musl
> would just return a zeroed mallinfo struct,
> because I don't even know if the function is
> called at all: I just know that the code won't
> compile without those symbols.
>
> Arguably, I can do that workaround myself,
> so I'll just do that for now.
>
> Thanks again for the quick reply!
> Gonzalo