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
Hi!
Pierre Neidhardt <mail <at> ambrevar.xyz> skribis:
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> I think the ‘lzread!’ loop should look like this (the tests still pass
>> with this):
>>
>> --8<---------------cut here---------------start------------->8---
>> (let loop ((read 0)
>> (start start))
>> (cond ((< read count)
>> (match (lz-decompress-read decoder bv start (- count read))
>> (0 (cond ((lz-decompress-finished? decoder)
>> read)
>> ((eof-object? (feed-decoder! decoder))
>> (lz-decompress-finish decoder)
>> (loop read start))
>> (else ;read again
>> (loop read start))))
>> (n (loop (+ read n) (+ start n)))))
>> (else
>> read)))
>> --8<---------------cut here---------------end--------------->8---
>
> Looks good to me!
OK, committed!
>>> (match (lz-decompress-read decoder bv start (- count read))
>>> (0 (if (eof-object? (feed-decoder! decoder))
>>> read
>>> (loop read start)))
>>>
>>> I'm not sure I understand the above: if we read nothing, then we try
>>> again?
>>
>> No: if we read *something*, we try again; if we read nothing, we return.
>
> If we read nothing _and_ it is not an EOF (it can be an empty vector),
> then we loop indefinitely, no?
‘feed-decoder!’ cannot return an empty bytevector because
‘lz-decompress-write-size’ necessarily returns a strictly positive
integer at this point.
(Imperative programming is hard! :-))
Thanks,
Ludo’.
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.