]> gitweb.michael.orlitzky.com - libsvgtiny.git/commit
Ensure path generation does not overrun allocated storage.
authorVincent Sanders <vince@kyllikki.org>
Thu, 15 Jan 2015 12:38:04 +0000 (12:38 +0000)
committerVincent Sanders <vince@kyllikki.org>
Thu, 15 Jan 2015 12:38:04 +0000 (12:38 +0000)
commitb314f3b54da7892d9f6994ba99082b92b76cf316
tree693146aba74da43d511eedb465f1cf60f9c8933c
parent7ec0aa7b69d32f2a545636f7dfbe31641d97d1fa
Ensure path generation does not overrun allocated storage.

This fixes bug #2251 which was caused by the svg:

<svg width="11" height="11" id="support-entry-icon"
y="3389"><g><g><path fill-rule="evenodd" clip-rule="evenodd"
fill="#D6D6D6" d="M0,0v11h11V0H0z M10,10H1V1h9V10z M9,3H2v1h7V3z
M9,5H2v1h7V5z M9,7H2v1h7V7z"/></g></g></svg>

The svg was causing more path elements to be generated in the internal
representation than space was allocated for and overrunning heap
blocks.

The path element parsing was using a fixed size allocation for the
path elements and never bounds checked. Further it did not cope with
zero length paths (which the spec says are permitted). It was also
grossly overallocating for the common case.

This changes the path element array to be bounds checked and then
extended if required, the initial allocation is generally sufficient
and in testing very few resizes occurred.

The reallocation strategy grows the element storage by 2.5 each time
this means even in the degenerate case very few reallocations are
required. In testing no more than a single reallocation has been
observed.

The final path element array will always be reallocted to the minimum
required size. This reduces overall memory usage which is useful with
complex scenes.
src/svgtiny.c