From: Andy Wingo <wingo@igalia.com>
To: ludo@gnu.org (Ludovic Courtès)
Cc: 30066@debbugs.gnu.org
Subject: bug#30066: 'get-bytevector-some' returns only 1 byte from unbuffered ports
Date: Fri, 12 Jan 2018 11:33:32 +0100 [thread overview]
Message-ID: <87mv1jnz7n.fsf@igalia.com> (raw)
In-Reply-To: <87o9lzs7rn.fsf@gnu.org> ("Ludovic Courtès"'s message of "Fri, 12 Jan 2018 11:15:08 +0100")
On Fri 12 Jan 2018 11:15, ludo@gnu.org (Ludovic Courtès) writes:
> Andy Wingo <wingo@igalia.com> skribis:
>
>> On Thu 11 Jan 2018 22:55, Mark H Weaver <mhw@netris.org> writes:
>
> [...]
>
>>>>> Out of curiosity, is there a reason why you're using an unbuffered port
>>>>> in your use case?
>>>>
>>>> It’s to implement redirect à la socat:
>>>>
>>>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=17af5d51de7c40756a4a39d336f81681de2ba447
>>>
>>> Why is an unbuffered port being used here? Can we change it to a
>>> buffered port?
>>
>> This was also a question I had! If you make it a buffered port at 4096
>> bytes (for example), then get-bytevector-some works exactly like you
>> want it to, no?
>
> It might work, but that’s more by chance no?
No, it is reliable. get-bytevector-some on a buffered port must either
return all the buffered bytes or perform exactly one read (up to the
buffer size) and either return those bytes or EOF. As far as I
understand, that is exactly what you want.
Using buffered ports has two additional advantages: you get to specify
the read size, and returned bytevectors can be allocated to precisely
the right size (no need to overallocate then truncate).
Andy
next prev parent reply other threads:[~2018-01-12 10:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 15:02 bug#30066: 'get-bytevector-some' returns only 1 byte from unbuffered ports Ludovic Courtès
2018-01-10 15:59 ` Ludovic Courtès
2018-01-10 16:32 ` Andy Wingo
2018-01-10 16:58 ` Nala Ginrut
2018-01-10 17:26 ` Andy Wingo
2018-01-10 17:43 ` Nala Ginrut
2018-01-11 14:34 ` Ludovic Courtès
2018-01-11 19:55 ` Mark H Weaver
2018-01-11 21:02 ` Ludovic Courtès
2018-01-11 21:55 ` Mark H Weaver
2018-01-12 9:01 ` Andy Wingo
2018-01-12 10:15 ` Ludovic Courtès
2018-01-12 10:33 ` Andy Wingo [this message]
2018-01-13 20:53 ` Ludovic Courtès
2018-02-16 13:19 ` Ludovic Courtès
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=87mv1jnz7n.fsf@igalia.com \
--to=wingo@igalia.com \
--cc=30066@debbugs.gnu.org \
--cc=ludo@gnu.org \
/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).