From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509 Date: Sat, 06 Jun 2009 16:31:57 +0200 Message-ID: <878wk577s2.fsf@gnu.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1244298758 13380 80.91.229.12 (6 Jun 2009 14:32:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jun 2009 14:32:38 +0000 (UTC) Cc: guile-devel@gnu.org To: "Andy Wingo" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jun 06 16:32:35 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MCwwj-0005Cx-OD for guile-devel@m.gmane.org; Sat, 06 Jun 2009 16:32:34 +0200 Original-Received: from localhost ([127.0.0.1]:39481 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCwwj-0006Ld-52 for guile-devel@m.gmane.org; Sat, 06 Jun 2009 10:32:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MCwwH-0005sM-Ox for guile-devel@gnu.org; Sat, 06 Jun 2009 10:32:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MCwwD-0005m3-0K for guile-devel@gnu.org; Sat, 06 Jun 2009 10:32:05 -0400 Original-Received: from [199.232.76.173] (port=59985 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MCwwC-0005ll-NL for guile-devel@gnu.org; Sat, 06 Jun 2009 10:32:00 -0400 Original-Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]:42464) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1MCwwC-0006yK-0t for guile-devel@gnu.org; Sat, 06 Jun 2009 10:32:00 -0400 X-IronPort-AV: E=Sophos;i="4.41,316,1241388000"; d="scan'208";a="41218723" Original-Received: from vpn71.saclay.inria.fr (HELO nixey) ([195.83.213.71]) by mail4-relais-sop.national.inria.fr with ESMTP; 06 Jun 2009 16:31:57 +0200 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 18 Prairial an 217 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: i686-pc-linux-gnu In-Reply-To: (Andy Wingo's message of "Fri, 05 Jun 2009 14:32:50 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8636 Archived-At: Hello, "Andy Wingo" writes: > +SCM_DEFINE (scm_uniform_array_to_bytevector, "uniform-array->bytevector", > + 1, 0, 0, (SCM array), > + "Return a newly allocated bytevector whose contents\n" > + "will be copied from the uniform array @var{array}.") > +#define FUNC_NAME s_scm_uniform_array_to_bytevector > +{ > + SCM contents, ret; > + size_t len; > + scm_t_array_handle h; > + const void *base; > + size_t sz; > + > + contents = scm_array_contents (array, SCM_BOOL_T); > + if (scm_is_false (contents)) > + scm_wrong_type_arg_msg (FUNC_NAME, 0, array, "uniform contiguous array"); > + > + scm_array_get_handle (contents, &h); > + > + base = scm_array_handle_uniform_elements (&h); > + len = h.dims->inc * (h.dims->ubnd - h.dims->lbnd + 1); > + sz = scm_array_handle_uniform_element_size (&h); > + > + ret = make_bytevector (len * sz); > + memcpy (SCM_BYTEVECTOR_CONTENTS (ret), base, len * sz); Is this memcpy valid in the case of shared arrays? Looks like we end up copying more elements than needed, but maybe it's better this way. > + uniform-array->bytevector I would not export it from `(rnrs bytevector)' given that it has nothing to do with RnRS. Also, I would make the new C functions private, given that they are not intended for general use AIUI. What d'ya think? Thanks, Ludo'.