From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 158F9BBFB for ; Wed, 22 Jun 2005 02:07:15 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j5M07EgZ000807 for ; Wed, 22 Jun 2005 02:07:14 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA07968 for ; Wed, 22 Jun 2005 02:07:13 +0200 (MET DST) Received: from rabbit.math.nagoya-u.ac.jp (rabbit.math.nagoya-u.ac.jp [133.6.130.5]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j5M07Bkd000803 for ; Wed, 22 Jun 2005 02:07:13 +0200 Received: from localhost (nat00-c2 [172.16.60.194]) by rabbit.math.nagoya-u.ac.jp (8.12.11/3.7W) with ESMTP id j5M079O2004666; Wed, 22 Jun 2005 09:07:09 +0900 (JST) Date: Wed, 22 Jun 2005 09:07:27 +0900 (JST) Message-Id: <20050622.090727.59467363.garrigue@math.nagoya-u.ac.jp> To: roessler@rftp.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] Runtime string allocation/resizing From: Jacques Garrigue In-Reply-To: <42B87C09.3020008@rftp.com> References: <42B87C09.3020008@rftp.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 42B8ABB2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42B8ABAF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 runtime:01 resizing:01 interfacing:01 ocaml:01 alloc:01 alloc:01 malloc:01 heap:01 malloc:01 buffer:01 ...:98 jacques:01 jacques:01 data:02 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: From: Robert Roessler > When dealing with OCaml-to-C-land interfacing, I sometimes am in the > position of needing to allocate and fill a string - but only have an > upper bound for the length... until after I have already copied the > data [from a third-party library function]. > > What is the recommended "OCaml" way to deal with this? > > Should I do two caml_alloc_string calls? One to initially "get" the > data, and then alloc a second one and copy to it after I know the > correct length? > > Or would it be considered better practice to use malloc in the C heap > for the "temp" copy and only do the caml_alloc_string when I know the > exact size? > > Or ? If your goal is raw performance, then probably the fastest approach would be to use alloca(). Unfortunately, this is not very portable. Using malloc() is not a very good idea either, as some implementations are really slow. So I would recommend using caml_alloc_string twice. Allocation costs amost nothing, and the added GC cost is really minimal. (But maybe GC specialists know better.) I you have a global bound on the size of the string, a static buffer is of course the best solution (but I suppose you would not have the question then.) Jacques