Re: Why is it that png files are not dependable over the long haul

Experimenting with the chromium modified zlib, I found a
flag  INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR

which almost works... but not quite.
https://drive.google.com/file/d/1lKWqsRSG5SnGFVvDx5VmjpNQqVpwptN6/view?usp=sharing

On Wed, Aug 1, 2018 at 10:55 PM J Decker <[email protected]> wrote:

> So there is a compile option for zlib to allow small frames?  That's why
> firefox and chrome WORK?
>
> chromium is #define ZLIB_VERSION "1.2.11"
> but... there are changes.
>
> #elif defined(Z_CR_PREFIX_SET)
> #    undef gzgetc
> #    define gzgetc(g) \
>           ((g)->have ? ((g)->have--, (g)->pos++, *((g)->next)++) \
>                      : (Cr_z_gzgetc)(g))
>
>     state->check = 1L;      /* 1L is the result of adler32() zero length
> data */
>
> several misc changes in deflate.c and crc32.c (which actually is expected
> to hook into like Cr_z_crc_* )
>
> ----
> Firefox has no modifications to zlib (names and type compatibility)
> /* This header does prefixing as below, but with an updated set of names.
> */
> #include "mozzconf.h"
>
> but has mods to 1.6.34 for at least APNG and seems all the changes are in
> #ifdef blocks; no existing code seems to be modified...
>
> which is just some additional block types(?)
>
> #ifdef PNG_READ_APNG_SUPPORTED
>       else if (chunk_name == png_acTL)
>          png_handle_acTL(png_ptr, info_ptr, length);
>
>       else if (chunk_name == png_fcTL)
>          png_handle_fcTL(png_ptr, info_ptr, length);
>
>       else if (chunk_name == png_fdAT)
>          png_handle_fdAT(png_ptr, info_ptr, length);
> #endif
>
> ---------------
> So firefox is really vanilla (again unless there's some compile
> flag/option that is getting set) Zlib build is pretty simple.
>
> mozilla build does enable optimzations for platforms with intrinsics
> (neon, SSE...) when building PNG...
>
>
> On Wed, Aug 1, 2018 at 9:25 PM Cosmin Truta <[email protected]> wrote:
>
>> Cosmin Truta wrote:
>>
>> > The PNG specification (and zlib, and deflate, etc.) have strict rules
>> > for error detection, but no rules for error recovery.
>>
>> Correction: the PNG spec does have rules for error recovery, for
>> ancillary chunks (e.g. signal, and then drop the bad ancillary chunks,
>> and then continue) but not for critical chunks. The error that we're
>> dealing with here is inside IDAT, which is a critical chunk containing
>> a critically-important, unfortunately broken zlib datastream.
>>
>> Also: general rules for error recovery do not specifically include
>> rules for data recovery. For example: if you have a chunk with
>> spurious data, it's intuitive to simply discard the spurious data. But
>> other than that, where nothing is spurious, and nothing is redundant
>> (as it is in our case), it is necessary to guess (because it is not
>> possible to absolutely know) how to recover the data. And guessing is
>> what we're doing here to solve this problem.
>>
>> Sincerely,
>> Cosmin
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> png-mng-implement mailing list
>> png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/png-mng-implement
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
png-mng-implement mailing list
png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-implement