From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:56767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hV0hV-0002KF-DY for guix-patches@gnu.org; Sun, 26 May 2019 17:29:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hV0hS-00044X-Ch for guix-patches@gnu.org; Sun, 26 May 2019 17:29:05 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:38423) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hV0hS-00044M-AM for guix-patches@gnu.org; Sun, 26 May 2019 17:29:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hV0hS-0005yF-4p for guix-patches@gnu.org; Sun, 26 May 2019 17:29:02 -0400 Subject: [bug#35880] [PATCH 7/7] lzlib: 'lzread!' never returns more than it was asked for. Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20190524134238.22802-1-ludo@gnu.org> <20190524134238.22802-7-ludo@gnu.org> <877eaeo2zr.fsf@ambrevar.xyz> <87zhn9kn3p.fsf@gnu.org> <87r28llyr4.fsf@ambrevar.xyz> Date: Sun, 26 May 2019 23:28:38 +0200 In-Reply-To: <87r28llyr4.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Sun, 26 May 2019 22:57:51 +0200") Message-ID: <87a7f8kird.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Pierre Neidhardt Cc: 35880@debbugs.gnu.org Pierre Neidhardt skribis: > Ludovic Court=C3=A8s writes: > >> Pierre Neidhardt skribis: >> >>>> Fixes a bug whereby 'lzread!' could return more than COUNT. >>> >>> Hmm... But why is this a bug? >> >> Because then the =E2=80=98read!=E2=80=99 method of the custom binary inp= ut port could >> return more than =E2=80=98count=E2=80=99, which is understandably not pe= rmitted. > > That's the part where I'm a bit confused because we deal with compressed > data here. > > So when we say "(read count)", does COUNT refer to the compressed or > uncompressed data? We have this: (define* (make-lzip-input-port port) (define decoder (lz-decompress-open)) (define (read! bv start count) (lzread! decoder port bv start count)) (make-custom-binary-input-port "lzip-input" read! #f #f (lambda () =E2=80=A6))) Here =E2=80=98read!=E2=80=99 must return an integer between 1 and COUNT; it= must return 0 if and only if the end-of-file is reached. IOW, =E2=80=98lzread!=E2=80=99 must return the number of uncompressed bytes= of BV that it consumed, and that number is necessarily <=3D COUNT. Does that make sense? Thanks, Ludo=E2=80=99.