Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #1962 > unrolled thread

Beginner's question about RFC 1951

Back to article view | Back to comp.compression

Contents

  Beginner's question about RFC 1951 Christoph-Simon Senjak <css@uxul.de> - 2013-05-31 15:25 +0200
    Re: Beginner's question about RFC 1951 Ian Clifton <ian.clifton@chem.ox.ac.uk> - 2013-05-31 15:33 +0100
      Re: Beginner's question about RFC 1951 Christoph-Simon Senjak <css@uxul.de> - 2013-05-31 17:35 +0200
        Re: Beginner's question about RFC 1951 Christoph-Simon Senjak <css@uxul.de> - 2013-05-31 23:36 +0200

#1962 — Beginner's question about RFC 1951

Hello.

I am currently trying to understand RFC 1951. I used the example file 
http://zlib.net/zpipe.c to generate a Deflate stream. I use the 
following program to dump the binary representation of the created 
deflate stream:

/* toBin.c */
#include <stdio.h>

void toString (int c, char* out) {
   int i;
   for (i = 0; i < 8; ++i) {
     out[i] = ((c >> i) % 2) == 0 ? '0' : '1';
   }
}

int main (void) {
   int c;
   char ts[9]; ts[8] = 0;
   while ((c = getchar()) != EOF) {
     toString(c, ts);
     printf("%s.", ts);
   }
}

Now, when running

$ echo "Hello World" | ./zpipe | ./toBin

I get a String starting with

00011110.00111001.11001111.00010010.10110011.

If I understand correctly, the leading bits 000 means "not the last 
block" and "no compression", according to RFC 1951. The next five bits 
are ignored, and then two times sixteen bits are used to indicate the 
length of the uncompressed block, and the should be the complement of 
each other, but as you can see, they are not.

I thought of maybe interpreting the bit-endianness wrong, but even if I 
reverse the first byte, it starts with 011, and the compression method 
11 is reserved, according to RFC 1951.

What am I missing? Sorry if this is a stupid question, but I am trying 
to understand the RFC, and I am not yet familiar with everything.

Best Regards,
Christoph-Simon Senjak

[toc] | [next] | [standalone]

#1963

Christoph-Simon Senjak <css@uxul.de> writes:

> Hello.
>
> I am currently trying to understand RFC 1951. I used the example file
> http://zlib.net/zpipe.c to generate a Deflate stream. I use the
> following program to dump the binary representation of the created
> deflate stream:
>
> /* toBin.c */
> #include <stdio.h>
>
> void toString (int c, char* out) {
>   int i;
>   for (i = 0; i < 8; ++i) {
>     out[i] = ((c >> i) % 2) == 0 ? '0' : '1';
>   }
> }
>
> int main (void) {
>   int c;
>   char ts[9]; ts[8] = 0;
>   while ((c = getchar()) != EOF) {
>     toString(c, ts);
>     printf("%s.", ts);
>   }
> }
>
> Now, when running
>
> $ echo "Hello World" | ./zpipe | ./toBin
>
> I get a String starting with
>
> 00011110.00111001.11001111.00010010.10110011.
>
> If I understand correctly, the leading bits 000 means "not the last
> block" and "no compression", according to RFC 1951. The next five bits
> are ignored, and then two times sixteen bits are used to indicate the
> length of the uncompressed block, and the should be the complement of
> each other, but as you can see, they are not.
>
> I thought of maybe interpreting the bit-endianness wrong, but even if
> I reverse the first byte, it starts with 011, and the compression
> method 11 is reserved, according to RFC 1951.
>
> What am I missing? Sorry if this is a stupid question, but I am trying
> to understand the RFC, and I am not yet familiar with everything.

I’m not familiar with C, so I can’t comment on how your “toBin” program
works; but whenever I’ve delved into things in this way, I’ve found you
need to be absolutely sure you know which bit‐positions in your bytes
(however you’re choosing to look at them) correspond to which
bit‐positions in the abstract standard—any room for doubt, and you’re
sure to get confused, in my experience!
-- 
Ian ◎

[toc] | [prev] | [next] | [standalone]

#1964

On 31.05.2013 16:33, Ian Clifton wrote:
> Christoph-Simon Senjak <css@uxul.de> writes:
>
>> Hello.
>>
>> I am currently trying to understand RFC 1951. I used the example file
>> http://zlib.net/zpipe.c to generate a Deflate stream. I use the
>> following program to dump the binary representation of the created
>> deflate stream:
>>
>> /* toBin.c */
>> #include <stdio.h>
>>
>> void toString (int c, char* out) {
>>    int i;
>>    for (i = 0; i < 8; ++i) {
>>      out[i] = ((c >> i) % 2) == 0 ? '0' : '1';
>>    }
>> }
>>
>> int main (void) {
>>    int c;
>>    char ts[9]; ts[8] = 0;
>>    while ((c = getchar()) != EOF) {
>>      toString(c, ts);
>>      printf("%s.", ts);
>>    }
>> }
>>
>> Now, when running
>>
>> $ echo "Hello World" | ./zpipe | ./toBin
>>
>> I get a String starting with
>>
>> 00011110.00111001.11001111.00010010.10110011.
>>
>> If I understand correctly, the leading bits 000 means "not the last
>> block" and "no compression", according to RFC 1951. The next five bits
>> are ignored, and then two times sixteen bits are used to indicate the
>> length of the uncompressed block, and the should be the complement of
>> each other, but as you can see, they are not.
>>
>> I thought of maybe interpreting the bit-endianness wrong, but even if
>> I reverse the first byte, it starts with 011, and the compression
>> method 11 is reserved, according to RFC 1951.
>>
>> What am I missing? Sorry if this is a stupid question, but I am trying
>> to understand the RFC, and I am not yet familiar with everything.
>
> I’m not familiar with C, so I can’t comment on how your “toBin” program
> works; but whenever I’ve delved into things in this way, I’ve found you
> need to be absolutely sure you know which bit‐positions in your bytes
> (however you’re choosing to look at them) correspond to which
> bit‐positions in the abstract standard—any room for doubt, and you’re
> sure to get confused, in my experience!

Thank you for your answer.

I coded the same in Haskell, and get the same results. RFC 1951 sais

       significant bit on the left.  In the diagrams below, we number the
       bits of a byte so that bit 0 is the least-significant bit, i.e.,
       the bits are numbered:

          +--------+
          |76543210|
          +--------+

and it sais

              * Data elements are packed into bytes in order of
                increasing bit number within the byte, i.e., starting
                with the least-significant bit of the byte.

Anyway, there are only two (usual) possibilities to read bytes: 
Least-Signifikant Bit first, and Least-Significant Bit last. And if I 
reverse the first byte "00011110", it starts with "011", which, 
according to 3.2.3 of RFC 1951, is "reserved (error)". That is, in both 
ways, it would not be compliant with RFC 1951, at least as far as I 
understood it.

Maybe the zlib-functions used in zpipe.c, despite their names, put an 
additional container-format around the deflate stream. But probably this 
can only be answered by somebody who is very familiar with the 
deflate-format.

Can somebody help me?

Best Regards,
CSS

[toc] | [prev] | [next] | [standalone]

#1965

Am 31.05.2013 17:35, schrieb Christoph-Simon Senjak:
> On 31.05.2013 16:33, Ian Clifton wrote:
>> Christoph-Simon Senjak <css@uxul.de> writes:
>>
>>> Hello.
>>>
>>> I am currently trying to understand RFC 1951. I used the example file
>>> http://zlib.net/zpipe.c to generate a Deflate stream. I use the
>>> following program to dump the binary representation of the created
>>> deflate stream:
>>>
>>> /* toBin.c */
>>> #include <stdio.h>
>>>
>>> void toString (int c, char* out) {
>>>    int i;
>>>    for (i = 0; i < 8; ++i) {
>>>      out[i] = ((c >> i) % 2) == 0 ? '0' : '1';
>>>    }
>>> }
>>>
>>> int main (void) {
>>>    int c;
>>>    char ts[9]; ts[8] = 0;
>>>    while ((c = getchar()) != EOF) {
>>>      toString(c, ts);
>>>      printf("%s.", ts);
>>>    }
>>> }
>>>
>>> Now, when running
>>>
>>> $ echo "Hello World" | ./zpipe | ./toBin
>>>
>>> I get a String starting with
>>>
>>> 00011110.00111001.11001111.00010010.10110011.
>>>
>>> If I understand correctly, the leading bits 000 means "not the last
>>> block" and "no compression", according to RFC 1951. The next five bits
>>> are ignored, and then two times sixteen bits are used to indicate the
>>> length of the uncompressed block, and the should be the complement of
>>> each other, but as you can see, they are not.
>>>
>>> I thought of maybe interpreting the bit-endianness wrong, but even if
>>> I reverse the first byte, it starts with 011, and the compression
>>> method 11 is reserved, according to RFC 1951.
>>>
>>> What am I missing? Sorry if this is a stupid question, but I am trying
>>> to understand the RFC, and I am not yet familiar with everything.
>>
>> I’m not familiar with C, so I can’t comment on how your “toBin” program
>> works; but whenever I’ve delved into things in this way, I’ve found you
>> need to be absolutely sure you know which bit‐positions in your bytes
>> (however you’re choosing to look at them) correspond to which
>> bit‐positions in the abstract standard—any room for doubt, and you’re
>> sure to get confused, in my experience!
>
> Thank you for your answer.
>
> I coded the same in Haskell, and get the same results. RFC 1951 sais
>
>        significant bit on the left.  In the diagrams below, we number the
>        bits of a byte so that bit 0 is the least-significant bit, i.e.,
>        the bits are numbered:
>
>           +--------+
>           |76543210|
>           +--------+
>
> and it sais
>
>               * Data elements are packed into bytes in order of
>                 increasing bit number within the byte, i.e., starting
>                 with the least-significant bit of the byte.
>
> Anyway, there are only two (usual) possibilities to read bytes:
> Least-Signifikant Bit first, and Least-Significant Bit last. And if I
> reverse the first byte "00011110", it starts with "011", which,
> according to 3.2.3 of RFC 1951, is "reserved (error)". That is, in both
> ways, it would not be compliant with RFC 1951, at least as far as I
> understood it.
>
> Maybe the zlib-functions used in zpipe.c, despite their names, put an
> additional container-format around the deflate stream. But probably this
> can only be answered by somebody who is very familiar with the
> deflate-format.
>
> Can somebody help me?

Ok, I found out that the ZLib wrapps around data specified in RFC 1950. 
That is probably the problem.

Best regards
CSS

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compression

csiph-web