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

Groups > comp.compression > #1965

Re: Beginner's question about RFC 1951

Show all headers | View raw

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

Back to comp.compression | Previous | Next — Previous 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