bug#18866: bytevector-copy creates srfi-4 vector with greater length

bug#18866: bytevector-copy creates srfi-4 vector with greater length

[tantalum]

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

see also http://lists.gnu.org/archive/html/guile-devel/2014-10/msg00064.html

bug#18866: bytevector-copy creates srfi-4 vector with greater length

[Mark H Weaver]

tantalum <sph@posteo.eu> 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
>
> see also http://lists.gnu.org/archive/html/guile-devel/2014-10/msg00064.html

I fixed this in 10679f4c59fcffb0657219e28e38d15df8ad09a0 by changing
'bytevector-copy' to always produce a standard bytevector with unsigned
8-bit elements, as if 'bytevector-copy' was implemented using the
standard procedures 'make-bytevector', 'bytevector-length', etc.
This is on the stable-2.0 branch and will be in Guile 2.0.12.

I'm open to the idea of adding another procedure that copies arbitrary
SRFI-4 vectors, but I think it should have a different name.  If you'd
like to persue this, let's create another ticket for it.

I'm closing this bug now.

      Thanks,
        Mark