From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Llorens Newsgroups: gmane.lisp.guile.devel Subject: Unexpected srfi-4 C Interface Change in 2.0.10 Date: Wed, 19 Mar 2014 18:04:39 +0100 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1395248707 29669 80.91.229.3 (19 Mar 2014 17:05:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2014 17:05:07 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 19 18:05:14 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WQJvS-000302-3O for guile-devel@m.gmane.org; Wed, 19 Mar 2014 18:05:10 +0100 Original-Received: from localhost ([::1]:42743 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQJvR-0005F7-Kr for guile-devel@m.gmane.org; Wed, 19 Mar 2014 13:05:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQJv8-0004nV-Km for guile-devel@gnu.org; Wed, 19 Mar 2014 13:04:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQJv2-000698-Vs for guile-devel@gnu.org; Wed, 19 Mar 2014 13:04:50 -0400 Original-Received: from zhhdzmsp-smta16.bluewin.ch ([195.186.227.132]:61226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQJv2-00068l-Ps for guile-devel@gnu.org; Wed, 19 Mar 2014 13:04:44 -0400 Original-Received: from [195.186.99.130] ([195.186.99.130:39304] helo=zhbdzmsp-smta11.bluewin.ch) by zhhdzmsp-smta16.bluewin.ch (envelope-from ) (ecelerity 3.5.7.40067 r(Platform:3.5.7.0)) with ESMTP id D0/7E-13081-92EC9235; Wed, 19 Mar 2014 17:04:41 +0000 Original-Received: from [172.16.96.17] (62.2.203.131) by zhbdzmsp-smta11.bluewin.ch (8.5.142) (authenticated as dll@bluewin.ch) id 51E5C44E12C59CCF for guile-devel@gnu.org; Wed, 19 Mar 2014 17:04:41 +0000 In-Reply-To: X-Mailer: Apple Mail (2.1085) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 195.186.227.132 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16986 Archived-At: > Message: 2 > Date: Wed, 19 Mar 2014 10:22:40 -0400 > From: Barry Fishman > To: guile-devel@gnu.org > Subject: Unexpected srfi-4 C Interface Change in 2.0.10 > Message-ID: > Content-Type: text/plain >=20 > When building C interface code using scm_f32vector_writable_elements() > in 2.0.10 and on the trunk I found: >=20 > For a vector generated in guile with: >=20 > (f32vector 0.25 0.25 0.25 1.0) >=20 > I found in the C interface: >=20 > scm_t_array_handle handle; > size_t vlen, vinc; > float *arrayp; >=20 > arrayp =3D scm_f32vector_writable_elements(s_uvec, &handle, > &vlen, &vinc) >=20 > When I test vlen it now seems to contain the number of bytes (16) > rather than the number of elements (4) in the f32vector. >=20 > It was 4 in 2.0.9 and the guile trunk I built on Jan 8. > It was 16 in 2.0.10 and the guile trunk I built on March 17. > I assume it relates to the Feb 8 changes, where: > (in commit dc65b88d839c326889618112c4870ad3a64e9446) >=20 > *lenp =3D scm_c_bytevector_length (uvec) / width; >=20 > and width is set to 1 in the macro: >=20 > DEFINE_SRFI_4_C_FUNCS (F32, f32, float, 1); This is a bug. Is there a test setup for the C interface? The last argument of DEFINE_SRFI_4_C_FUNCS (1) is correct; that can be 1 = or 2, because complex types use a pointer to real. We could use C99 = complex types and get rid of it. Just cast the pointer for C<99 users = (?) The bug appeared in replacing the deprecated = scm_uniform_vector_elements() with the bytevector functions. Generally = lengths are computed with scm_i_array_element_type_sizes[] in uniform.c = (e.g. see make_bytevector() in bytevector.c). So the patch would be *lenp =3D scm_c_bytevector_length (uvec) / (width * = scm_i_array_element_type_sizes[ETYPE (TAG)]) ; Actually I'd do *lenp =3D scm_c_bytevector_length (uvec) / (width * sizeof(ctype)) (Both untested). Regards, Daniel