GNU bug report logs -
#35880
[PATCH 0/7] Lzip support for 'guix publish' and 'guix substitute'
Previous Next
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Fri, 24 May 2019 13:34:02 UTC
Severity: normal
Tags: patch
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[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)]
This bug report was last modified 5 years and 350 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.