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

Groups > comp.compression > #1964

Re: Beginner's question about RFC 1951

Show all headers | View raw

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

Back to comp.compression | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web