Re: Dynamic arrays in libpng

>From a discussion on a diffent list (png-mng-misc) originally:

On Sun, Feb 5, 2017 at 2:45 PM, Cosmin Truta <[email protected]> wrote:
>
> For example, png_set_unknown_chunks() works well if all of the unknown
> chunks are added all at once; but not so well if they are added in
> repeated batches.

Indeed.  That, and the "text" case are why Greg (I think) put in an
increment to the buffer in question such that an incremental attack
would be reducted in effectiveness.  IRC the reduction factor was 5;
the array was reallocated 5 at a time.

> On the same topic, png_set_text() does a slightly better job,
> reallocating at each of the 8th insertion; but overall, the complexity
> of this algorithm is still quadratic.

Ok.  8.

> A dynamic array implementation, on the other hand, will guarantee an
> efficient N*log(N) execution, for all the arrays that need to be
> constructed dynamically.

Yep, you still have to implement the whole shebang.

> Would you (Glenn) accept such a contribution? This data structure may
> then serve as the basis for efficient iCCP implementation also.

I think you will find the iCCP handling in 1.6 is efficient; you
clearly didn't look at it.

However beyond the snarky comment I just made; YES YES YES.  Fixing
those things without messing with the API, would, at least from my
point of view, be welcome.

I tried, I failed; I got drawn into my own
this-is-fucked-I-need-to-rewrite-it mentality.  1.6 was difficult
(hence 1.5; the darned simplified API wouldn't fit into the bucket).
I'm out there at present; every night I dream about 1.7 and every time
I dream I see a problem.

Simple fixes to obvious [potential] security issues will certainly benefit 1.6.

-- 
John Bowler <[email protected]>
+1 (541) 450-9885
PO BOX 3151
KERBY OR 97531-3151
USA

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