* [PATCH 1/2] docs: lzo: fix first byte interpretation off-by-one
@ 2020-05-22 14:10 C. Masloch
2020-05-22 14:10 ` [PATCH 2/2] docs: lzo: fix incorrect statement about distance zero for EOS C. Masloch
2020-05-22 15:22 ` [PATCH 1/2] docs: lzo: fix first byte interpretation off-by-one Dave Rodgman
0 siblings, 2 replies; 4+ messages in thread
From: C. Masloch @ 2020-05-22 14:10 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jonathan Corbet, Dave Rodgman, Willy Tarreau,
Andrew Morton
There was an error in the description of the initial byte's
interpretation. While "18..21" was listed as "copy 0..3 literals",
it should actually be interpreted as "copy 1..4 literals".
The "byte - 17" part is correct. 17 would encode copying "zero"
literals, but does not occur. 18 encodes copying 1 literal,
19 then 2 literals, 20 for 3 literals, 21 for 4 literals.
The description should read "18..21" as "copy 1..4 literals".
Likewise, 22 indicates "copying 5 literals", not "4 literals".
However, the state is indeed always set to "byte - 17" (which
for 21 results in 4 too).
Signed-off-by: C. Masloch <pushbx@ulukai.org>
---
Documentation/lzo.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/lzo.txt b/Documentation/lzo.txt
index ca9833289..f839d104d 100644
--- a/Documentation/lzo.txt
+++ b/Documentation/lzo.txt
@@ -108,12 +108,12 @@ Byte sequences
(version 1 only).
Otherwise, the bitstream version is 0.
- 18..21 : copy 0..3 literals
- state = (byte - 17) = 0..3 [ copy <state> literals ]
+ 18..21 : copy 1..4 literals
+ state = (byte - 17) = 1..4 [ copy <state> literals ]
skip byte
22..255 : copy literal string
- length = (byte - 17) = 4..238
+ length = (byte - 17) = 5..238
state = 4 [ don't copy extra literals ]
skip byte
--
2.26.2
^ permalink raw reply related [flat|nested] 4+ messages in thread* [PATCH 2/2] docs: lzo: fix incorrect statement about distance zero for EOS
2020-05-22 14:10 [PATCH 1/2] docs: lzo: fix first byte interpretation off-by-one C. Masloch
@ 2020-05-22 14:10 ` C. Masloch
2020-05-22 15:22 ` Dave Rodgman
2020-05-22 15:22 ` [PATCH 1/2] docs: lzo: fix first byte interpretation off-by-one Dave Rodgman
1 sibling, 1 reply; 4+ messages in thread
From: C. Masloch @ 2020-05-22 14:10 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jonathan Corbet, Dave Rodgman, Willy Tarreau,
Andrew Morton
The encoded distance bits are zero, but the distance that is
calculated from this is actually equal to 16384. So correct
this statement to read that the 0001HLLL instruction means
EOS when a distance of 16384 is seen. This matches with the
description of the instruction itself later on.
Signed-off-by: C. Masloch <pushbx@ulukai.org>
---
Documentation/lzo.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/lzo.txt b/Documentation/lzo.txt
index f839d104d..dc9e876cb 100644
--- a/Documentation/lzo.txt
+++ b/Documentation/lzo.txt
@@ -65,9 +65,9 @@ Description
generally encoded in the last two bits of the instruction but may also be
taken from the last two bits of an extra operand (eg: distance).
- End of stream is declared when a block copy of distance 0 is seen. Only one
- instruction may encode this distance (0001HLLL), it takes one LE16 operand
- for the distance, thus requiring 3 bytes.
+ End of stream is declared when a block copy of distance 16384 is seen,
+ encoded in a certain instruction (0001HLLL) with the H and D bits all zero.
+ It takes one LE16 operand for the distance, thus requiring 3 bytes.
.. important::
--
2.26.2
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH 2/2] docs: lzo: fix incorrect statement about distance zero for EOS
2020-05-22 14:10 ` [PATCH 2/2] docs: lzo: fix incorrect statement about distance zero for EOS C. Masloch
@ 2020-05-22 15:22 ` Dave Rodgman
0 siblings, 0 replies; 4+ messages in thread
From: Dave Rodgman @ 2020-05-22 15:22 UTC (permalink / raw)
To: C. Masloch, linux-doc
Cc: linux-kernel, Jonathan Corbet, Willy Tarreau, Andrew Morton
Looks good to me, thanks
Dave
On 22/05/2020, 15:11, "C. Masloch" <pushbx@ulukai.org> wrote:
The encoded distance bits are zero, but the distance that is
calculated from this is actually equal to 16384. So correct
this statement to read that the 0001HLLL instruction means
EOS when a distance of 16384 is seen. This matches with the
description of the instruction itself later on.
Signed-off-by: C. Masloch <pushbx@ulukai.org>
---
Documentation/lzo.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/lzo.txt b/Documentation/lzo.txt
index f839d104d..dc9e876cb 100644
--- a/Documentation/lzo.txt
+++ b/Documentation/lzo.txt
@@ -65,9 +65,9 @@ Description
generally encoded in the last two bits of the instruction but may also be
taken from the last two bits of an extra operand (eg: distance).
- End of stream is declared when a block copy of distance 0 is seen. Only one
- instruction may encode this distance (0001HLLL), it takes one LE16 operand
- for the distance, thus requiring 3 bytes.
+ End of stream is declared when a block copy of distance 16384 is seen,
+ encoded in a certain instruction (0001HLLL) with the H and D bits all zero.
+ It takes one LE16 operand for the distance, thus requiring 3 bytes.
.. important::
--
2.26.2
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 1/2] docs: lzo: fix first byte interpretation off-by-one
2020-05-22 14:10 [PATCH 1/2] docs: lzo: fix first byte interpretation off-by-one C. Masloch
2020-05-22 14:10 ` [PATCH 2/2] docs: lzo: fix incorrect statement about distance zero for EOS C. Masloch
@ 2020-05-22 15:22 ` Dave Rodgman
1 sibling, 0 replies; 4+ messages in thread
From: Dave Rodgman @ 2020-05-22 15:22 UTC (permalink / raw)
To: C. Masloch, linux-doc
Cc: linux-kernel, Jonathan Corbet, Willy Tarreau, Andrew Morton
Your update looks correct to me, thanks.
Dave
On 22/05/2020, 15:11, "C. Masloch" <pushbx@ulukai.org> wrote:
There was an error in the description of the initial byte's
interpretation. While "18..21" was listed as "copy 0..3 literals",
it should actually be interpreted as "copy 1..4 literals".
The "byte - 17" part is correct. 17 would encode copying "zero"
literals, but does not occur. 18 encodes copying 1 literal,
19 then 2 literals, 20 for 3 literals, 21 for 4 literals.
The description should read "18..21" as "copy 1..4 literals".
Likewise, 22 indicates "copying 5 literals", not "4 literals".
However, the state is indeed always set to "byte - 17" (which
for 21 results in 4 too).
Signed-off-by: C. Masloch <pushbx@ulukai.org>
---
Documentation/lzo.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/lzo.txt b/Documentation/lzo.txt
index ca9833289..f839d104d 100644
--- a/Documentation/lzo.txt
+++ b/Documentation/lzo.txt
@@ -108,12 +108,12 @@ Byte sequences
(version 1 only).
Otherwise, the bitstream version is 0.
- 18..21 : copy 0..3 literals
- state = (byte - 17) = 0..3 [ copy <state> literals ]
+ 18..21 : copy 1..4 literals
+ state = (byte - 17) = 1..4 [ copy <state> literals ]
skip byte
22..255 : copy literal string
- length = (byte - 17) = 4..238
+ length = (byte - 17) = 5..238
state = 4 [ don't copy extra literals ]
skip byte
--
2.26.2
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-05-22 15:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-22 14:10 [PATCH 1/2] docs: lzo: fix first byte interpretation off-by-one C. Masloch
2020-05-22 14:10 ` [PATCH 2/2] docs: lzo: fix incorrect statement about distance zero for EOS C. Masloch
2020-05-22 15:22 ` Dave Rodgman
2020-05-22 15:22 ` [PATCH 1/2] docs: lzo: fix first byte interpretation off-by-one Dave Rodgman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).