Re: [feature request] add mallinfo support

[Dmitry Golovin <dima@golovin.in>]

> 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