tantalum <s...@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 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-gu...@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.
Thoughts?
Mark
