Literal/Length code with 256-wide sub-tree a problem about zlib6502

[pfusik]

Thank you for reporting this. How did you get this stream?

I will try to fix the routine. Is the workaround of detecting this case and recompressing the data to avoid the problem acceptable for you?

[pfusik]

I fixed this by getting rid of nbitCode_totalCount. This even saves 7 bytes of code. The cost is slower fetchCode - zopfli-compressed GPL v3 takes 3% more time.

Now I wonder if:

• more than 256 codes of same length
• all 256 literal codes of same length

are possible? If you are able to generate such streams, please submit separate issues.

Thank you!

[gp48k]

Wow, fast work. rep16.bin.gz comes from using standard gzip on a file I created specially. All I did was create some data that is compressible and only has 1 occurrence of literal values 0 .. 254. Since 256 (end of block code) appears once there are 256 symbols with the same frequency so the Huffman encoding gives them the same code length. Here's the little C program I wrote:

int main(int argc, char *argv[])
{
	int i, j;
	FILE *fp = fopen("rep16.bin", "wb");
	for (i = 0; i < 255; i++) {
		int n = i == 0 ? 1 : 16;
		for (j = 0; j < n; j++) {
			fputc(i, fp);
		}
	}
	fclose(fp);
	return 0;
}

I think both trees you suggest are possible by directly constructing the deflate data. I'm not so sure if one could make a data file that results in those trees when run through gzip. I'll have to think about that.