On 26/04/2024 6:57 am, Jan Beulich wrote:
> On 26.04.2024 07:55, Jan Beulich wrote:
>> On 25.04.2024 21:23, Andrew Cooper wrote:
>>> On 24/04/2024 5:34 pm, Daniel P. Smith wrote:
>>>> --- a/xen/common/gzip/inflate.c
>>>> +++ b/xen/common/gzip/inflate.c
>>>> @@ -1017,8 +1014,8 @@ static int __init inflate(struct gunzip_state *s)
>>>> /* Undo too much lookahead. The next read will be byte aligned so we
>>>> * can discard unused bits in the last meaningful byte.
>>>> */
>>>> - while (bk >= 8) {
>>>> - bk -= 8;
>>>> + while (s->bk >= 8) {
>>>> + s->bk -= 8;
>>>> s->inptr--;
>>>> }
>>> Isn't it just me, but isn't this just:
>>>
>>> s->inptr -= (s->bk >> 3);
>>> s->bk &= 7;
>>>
>>> ?
>> I'd say yes, if only there wasn't the comment talking of just a single byte,
>> and even there supposedly some of the bits.
The comments in this file leave a lot to be desired...
I'm reasonably confident they were not adjusted when a piece of
userspace code was imported into Linux.
This cannot ever have been just a byte's worth of bits, seeing as the
bit count is from 8 or more. Right now it's an unsigned long's worth of
bits.
> Talking of the comment: Considering what patch 1 supposedly does, how come
> that isn't Xen-style (yet)?
I had been collecting some minor fixes like this to fold into patch 1
when I committed the whole series.
I'll see if I can fold them elsewhere.
~Andrew
