From owner-freebsd-current@FreeBSD.ORG  Sat Nov 30 09:34:41 2013
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id BB88D1AB
 for <freebsd-current@freebsd.org>; Sat, 30 Nov 2013 09:34:41 +0000 (UTC)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
 (using TLSv1 with cipher AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id 7368015C9
 for <freebsd-current@freebsd.org>; Sat, 30 Nov 2013 09:34:41 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
 (envelope-from <freebsd-current@m.gmane.org>) id 1Vmgwb-0000wi-Qa
 for freebsd-current@freebsd.org; Sat, 30 Nov 2013 10:34:37 +0100
Received: from 79-139-19-75.prenet.pl ([79.139.19.75])
 by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
 id 1AlnuQ-0007hv-00
 for <freebsd-current@freebsd.org>; Sat, 30 Nov 2013 10:34:33 +0100
Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1
 (Debian)) id 1AlnuQ-0007hv-00
 for <freebsd-current@freebsd.org>; Sat, 30 Nov 2013 10:34:33 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-current@freebsd.org
From: jb <jb.1234abcd@gmail.com>
Subject: Re: [RFC] how to get the size of a malloc(9) block ?
Date: Sat, 30 Nov 2013 09:34:13 +0000 (UTC)
Lines: 24
Message-ID: <loom.20131130T102729-687@post.gmane.org>
References: <CA+hQ2+gK1pc_aS1LEKp29Bi=MHFtJCkw2uOrib_9wQ-7AziH=w@mail.gmail.com>
 <loom.20131130T002152-608@post.gmane.org>
 <CA+hQ2+j0cYW0dfhEtMGRXWhXhS=VF_N_ZB=JmcqRUofFKWXFiQ@mail.gmail.com>
 <loom.20131130T012034-966@post.gmane.org>
 <CA+hQ2+iCjnxUMP0v6d5ez=n07MBT5hLXzoa+1wTff3Wrtm=SHQ@mail.gmail.com>
 <52995C15.7010903@gmx.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686;
 rv:25.0) Gecko/20100101 Firefox/25.0)
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.16
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Nov 2013 09:34:41 -0000

 <dt71 <at> gmx.com> writes:

> ... 
> It appears that it's not possible to make a proper API with 
> malloc_usable_size() included, at least when
> multi-threading is involved (ie., in the modern world).
> 
> However, it is still useful to create an API that supports the following
cases:
> ...

Well, this is a step forward toward achieving a well defined API for memory
reallocation.

But can we arrive at this goal without consideration for leaked
implementation details via malloc_usable_size() & co ?
We want to get rid of that leak and associated hacks.

We want to induce reallocation function to do "the right thing" thru one API
call with clear and smart options.
If it does 90% of what we would ideally want, then the job is done.

jb