From dev-return-37329-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Sun Jan 7 16:32:30 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id D64DB180654 for ; Sun, 7 Jan 2018 16:32:30 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id C65C8160C29; Sun, 7 Jan 2018 15:32:30 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3E96C160C17 for ; Sun, 7 Jan 2018 16:32:30 +0100 (CET) Received: (qmail 5955 invoked by uid 500); 7 Jan 2018 15:32:29 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 5945 invoked by uid 99); 7 Jan 2018 15:32:29 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Jan 2018 15:32:29 +0000 Received: from zulu.23.e-reka.si (89-233-126-4.dynamic.t-2.net [89.233.126.4]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id AB4A71A0279 for ; Sun, 7 Jan 2018 15:32:26 +0000 (UTC) Subject: Re: [PATCH] swig-py svn_stream_t read() glue To: dev@subversion.apache.org References: <20180104045543.rzx7pt22n74d4xml@tarpaulin.shahaf.local2> From: =?UTF-8?Q?Branko_=c4=8cibej?= Organization: The Apache Software Foundation Message-ID: Date: Sun, 7 Jan 2018 16:32:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB On 07.01.2018 16:17, Troy Curtis Jr wrote: > On Wed, Jan 3, 2018 at 10:55 PM Daniel Shahaf > wrote: > >> svn_swig_py_make_stream() is a function that wraps a PyObject in an >> svn_stream_t. Its read implementation, read_handler_pyio(), just calls >> the PyObject's .read() method. >> >> According to >> , >> the read() method of "raw" file-like objects makes only one read(2) >> syscall, and so may return fewer bytes than were requested. (The py3 >> docs are similar.) >> >> > Probably in practice the passed in objects are one of the buffered types > where the read() behaves as this code obviously expected, which is likely > why this hasn't been noticed before. However, we can't actually *know* > that, and anything with a read() method would actually be perfectly valid. > So it seems like a good patch to me. I agree. Though not buffered streams but files; reading from a file will always behave as a full read whilst reading from a socket or pipe or fifo will not. Anyway +1 for the patch. The full-read functionality is simulated at the stream API implementation level if there's no specific full-read function. -- Brane