[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bytevector-copy creates srfi-4 vector with greater length

From: Mark H Weaver
Subject: Re: bytevector-copy creates srfi-4 vector with greater length
Date: Wed, 12 Nov 2014 01:15:44 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Mark H Weaver <address@hidden> writes:

> tantalum <address@hidden> writes:
>> with guile version 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 address@hidden 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]