From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: bytevector-copy creates srfi-4 vector with greater length Date: Wed, 12 Nov 2014 01:15:44 -0500 Message-ID: <87r3x9gd0v.fsf@yeeloong.lan> References: <544D09F6.8060309@posteo.eu> <87sii9j3ss.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415773044 27068 80.91.229.3 (12 Nov 2014 06:17:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Nov 2014 06:17:24 +0000 (UTC) Cc: guile-devel@gnu.org To: tantalum Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Nov 12 07:17:19 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 1XoRF0-0003vm-Fx for guile-devel@m.gmane.org; Wed, 12 Nov 2014 07:17:18 +0100 Original-Received: from localhost ([::1]:52635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoREz-0001rJ-SW for guile-devel@m.gmane.org; Wed, 12 Nov 2014 01:17:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoREq-0001qt-9K for guile-devel@gnu.org; Wed, 12 Nov 2014 01:17:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoREl-0006He-Dd for guile-devel@gnu.org; Wed, 12 Nov 2014 01:17:08 -0500 Original-Received: from world.peace.net ([96.39.62.75]:43740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoREl-0006HW-9W for guile-devel@gnu.org; Wed, 12 Nov 2014 01:17:03 -0500 Original-Received: from c-24-62-95-23.hsd1.ma.comcast.net ([24.62.95.23] helo=yeeloong.lan) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XoREe-0004RC-0M; Wed, 12 Nov 2014 01:16:56 -0500 In-Reply-To: <87sii9j3ss.fsf@netris.org> (Mark H. Weaver's message of "Mon, 27 Oct 2014 04:49:07 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:17606 Archived-At: Mark H Weaver writes: > tantalum writes: > >> with guile version 2.1.0.89-c5ea7 on an x86_64 GNU/Linux system >> and the following code >> (use-modules (srfi srfi-4) (rnrs bytevectors)) >> (define a (make-f32vector 2 0)) >> (define b (bytevector-copy a)) >> (write (list a b)) >> >> "b" turns out to be an f32vector with length 8, 4 times the length of "a". >> i expected the result to have the same length as the argument and this >> looks like a bug to me > > Yes, this is definitely a bug, introduced in 2009, commit > e286c973fcd63c0930d9302cc5f1a280b9b22615. > > Can you please send an email to bug-guile@gnu.org about it, so that it > will be assigned a bug number and ticket? That's the proper place to > send bug reports. > > I'm not sure whether 'bytevector-copy' should produce a SRFI-4 vector > with the same element type as its argument, or if it should produce a > normal bytevector with 8-bit elements. The argument for the latter > would be that 'bytevector-copy' is a standard procedure that portable > code might reasonably expect to produce bytevectors that print as > vectors of 8-bit bytes. I don't see a compelling argument for the > former, other than to provide a convenient way to copy SRFI-4 vectors. I ended up fixing this in 10679f4c59fcffb0657219e28e38d15df8ad09a0 by making 'bytevector-copy' always produce standard bytevectors with unsigned 8-bit elements. FYI, the bug ticket for this was . If there's demand for a convenient way to copy SRFI-4 vectors, let's give it a different name. Thanks, Mark