From: Mark H Weaver <mhw@netris.org>
To: tantalum <sph@posteo.eu>
Cc: guile-devel@gnu.org
Subject: Re: bytevector-copy creates srfi-4 vector with greater length
Date: Wed, 12 Nov 2014 01:15:44 -0500 [thread overview]
Message-ID: <87r3x9gd0v.fsf@yeeloong.lan> (raw)
In-Reply-To: <87sii9j3ss.fsf@netris.org> (Mark H. Weaver's message of "Mon, 27 Oct 2014 04:49:07 -0400")
Mark H Weaver <mhw@netris.org> writes:
> 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 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
<http://bugs.gnu.org/18866>.
If there's demand for a convenient way to copy SRFI-4 vectors, let's
give it a different name.
Thanks,
Mark
prev parent reply other threads:[~2014-11-12 6:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-26 14:49 bytevector-copy creates srfi-4 vector with greater length tantalum
2014-10-27 8:49 ` Mark H Weaver
2014-10-27 11:00 ` Taylan Ulrich Bayırlı/Kammer
2014-10-27 12:36 ` tantalum
2014-11-12 6:15 ` Mark H Weaver [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r3x9gd0v.fsf@yeeloong.lan \
--to=mhw@netris.org \
--cc=guile-devel@gnu.org \
--cc=sph@posteo.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).