Date: Thu, 18 Jan 2018 10:28:35 +0100 From: Gonzalo Brito Gadeschi <gonzalo.gadeschi@...h-aachen.de> To: Rich Felker <dalias@...c.org> CC: <musl@...ts.openwall.com> Subject: Re: [feature request] add mallinfo support 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 Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.