[ scummvm-Bugs-1504440 ] TOOLS: Suspect behaviour in encode_dxa

[SourceForge.net]

Bugs item #1504440, was opened at 2006-06-11 20:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418820&aid=1504440&group_id=37116

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unknown Crash/Other
Group: Tools
Status: Open
Resolution: None
Priority: 5
Submitted By: Torbjörn Andersson (eriktorbjorn)
Assigned to: Nobody/Anonymous (nobody)
Summary: TOOLS: Suspect behaviour in encode_dxa

Initial Comment:
Since there have been some recent reports about
encode_dxa claiming PNG files were not as expected on
some systems, I looked a bit closer at it, and there's
one thing that's puzzling me:

We call read_png_file() from within a loop. The first
time we call it, neither 'image' nor 'palette' are
initialized, so they may or may not be NULL.

Therefore, if read_png_file() fails the first time,
we'll either get the "8-bit 256-color" warning, or
we'll try and free at least one invalid pointer.

If read_png_file() succeeds, and 'palette' was
automatically initialized to an invalid pointer, a new
palette will be allocated, and things will work as
expected, I guess. But if 'palette' was automatically
initialized to NULL, it will not allocate a new
palette, and then we'd get that "8-bit 256-color" warning.

At least, that's what I think would happen. I'm not all
that familiar with libpng, and I don't want to
experiment with it without discussing it with Kirben...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418820&aid=1504440&group_id=37116