GNU bug report logs - #35880
[PATCH 0/7] Lzip support for 'guix publish' and 'guix substitute'

Previous Next

Full log

Message #29 received at 35880 <at> debbugs.gnu.org (full text, mbox):

From: Pierre Neidhardt <mail <at> ambrevar.xyz>
To: Ludovic Courtès <ludo <at> gnu.org>, 35880 <at> debbugs.gnu.org
Cc: Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: [PATCH 1/7] lzlib: Add 'make-lzip-input-port/compressed'.
Date: Sat, 25 May 2019 19:24:33 +0200

[Message part 1 (text/plain, inline)]

As an Lzip enthusiast, I have some questions ;)

I see you are using make-lzip-input-port/compressed in a subsequent
patch, but this does not map how it's done for gzip et al., the latter
being invoked via it's system command "gzip -c ...".  Why did you decide
to do it differently for lzip?

Much of the code induced by make-lzip-input-port/compressed seems to
repeat the lzread! / lzwrite business, maybe there is a way to factor
some of it?

> +(define (lzwrite! encoder source source-offset source-count
> +                  target target-offset target-count)
> +  "Write up to SOURCE-COUNT bytes from SOURCE to ENCODER, and read up to
> +TARGET-COUNT bytes into TARGET at TARGET-OFFSET.  Return two values: the
> +number of bytes read from SOURCE, and the number of bytes written to TARGET."
> +  (define read
> +    (if (< 0 (lz-compress-write-size encoder))
> +        (match (lz-compress-write encoder source source-offset source-count)
> +          (0 (lz-compress-finish encoder) 0)
> +          (n n))
> +        0))
> +
> +  (let loop ()
> +    (match (lz-compress-read encoder target target-offset target-count)
> +      (0       (loop))
> +      (written (values read written)))))

Why looping on 0?  If there is no byte to read, wouldn't this loop indefinitely?


-- 
Pierre Neidhardt
https://ambrevar.xyz/

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.