From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12372 Path: news.gmane.org!.POSTED!not-for-mail From: Gonzalo Brito Gadeschi Newsgroups: gmane.linux.lib.musl.general Subject: Re: [feature request] add mallinfo support Date: Thu, 18 Jan 2018 10:28:35 +0100 Message-ID: References: <20180117174325.GP1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11407c0666c11b05630998f4" X-Trace: blaine.gmane.org 1516276592 17614 195.159.176.226 (18 Jan 2018 11:56:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 Jan 2018 11:56:32 +0000 (UTC) Cc: To: Rich Felker Original-X-From: musl-return-12388-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 18 12:56:28 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ec8nv-00042Z-Bj for gllmg-musl@m.gmane.org; Thu, 18 Jan 2018 12:56:23 +0100 Original-Received: (qmail 9410 invoked by uid 550); 18 Jan 2018 11:58:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 16019 invoked from network); 18 Jan 2018 09:29:19 -0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CFIAACaGBa/5gagoZdHAEBAQQBAQoBA?= =?us-ascii?q?YNBZoEig1aBOZdJggKDf5VHChgBCoUYAoRTB0MUAQEBAQEBAQEBayiFJAEBAwE?= =?us-ascii?q?BIksLBQsLBAcDNAICIgYMAQUBHAYOijAIEJpCQIwTgieJTgEBAQEGAQEBAQEBA?= =?us-ascii?q?SEJAYQyghWBV4UWgTCBfwGFCYJlBZl5iXOBGI4khheMIIdzlwICAgICCQIGFAU?= =?us-ascii?q?ggRc2IoFQMhokUTIGgXMIhE+MAwGBFgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2CFIAACaGBa/5gagoZdHAEBAQQBAQoBAYNBZoEig1aBOZd?= =?us-ascii?q?JggKDf5VHChgBCoUYAoRTB0MUAQEBAQEBAQEBayiFJAEBAwEBIksLBQsLBAcDN?= =?us-ascii?q?AICIgYMAQUBHAYOijAIEJpCQIwTgieJTgEBAQEGAQEBAQEBASEJAYQyghWBV4U?= =?us-ascii?q?WgTCBfwGFCYJlBZl5iXOBGI4khheMIIdzlwICAgICCQIGFAUggRc2IoFQMhokU?= =?us-ascii?q?TIGgXMIhE+MAwGBFgEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,376,1511823600"; d="scan'208,217";a="34411572" X-Gm-Message-State: AKwxytdp2jcfXEadWr1bUxonpgrn2gW1Ldu2zyeJuM5YgNdEQcxYILvJ 6/uwEqQfxw+xXGsJyWR2slF9/QBZyGBGwQkToZg= X-Google-Smtp-Source: ACJfBos0nkbOMQYcmwY8N0+8AKm14fZRnkX2Elp/8XYilWG9Hx5BI+17/675Qu6gfF9I4+RqfrrY0FvO7AR+PUg8gvM= X-Received: by 10.157.61.55 with SMTP id a52mr2762191otc.326.1516267746277; Thu, 18 Jan 2018 01:29:06 -0800 (PST) In-Reply-To: <20180117174325.GP1627@brightrain.aerifal.cx> X-Gmail-Original-Message-ID: X-Originating-IP: [74.125.82.182] X-ClientProxiedBy: rwthex-s2-b.rwth-ad.de (2002:8682:1a9b::8682:1a9b) To rwthex-s1-a.rwth-ad.de (2002:8682:1a98::8682:1a98) Xref: news.gmane.org gmane.linux.lib.musl.general:12372 Archived-At: --001a11407c0666c11b05630998f4 Content-Type: text/plain; charset="UTF-8" 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 --001a11407c0666c11b05630998f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the quick reply.

> Omission of mallin= fo 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 <= br>the mailing list (or musl website for a bug tracker) without=C2=A0
a= ny luck.

> The API is fundamentally
broken (using type int whi= ch cannot represent sizes) and tracking the
information it provides impo= ses nontrivial costs on the malloc
implementation.

I agree.
> http://w= ww.openwall.com/lists/musl/2013/11/09/2
I went through the thread an= d could not find the piece of information
that lead to that opinion (may= be I am just generally bad at mailing lists).

Rich Felker (you :D) a= rgued:

> 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
> thr= eads on each call to malloc/free. (glibc does some poor
> hack keepin= g this info per-arena and summarizing it when
mallinfo is called, I thin= k...)

And Szabolcs Nagy just answered:

> i see

That= 's all I found there.

FWIW I wouldn't mind if mallinfo on mu= sl
would just return a zeroed mallinfo struct,
because I don't e= ven know if the function is
called at all: I just know that the code wo= n't
compile without those symbols.

Arguably, I can do that wo= rkaround myself,
so I'll just do that for now.

Thanks again = for the quick reply!
Gonzalo
--001a11407c0666c11b05630998f4--