Opened 18 years ago
Closed 18 years ago
#2670 closed defect (fixed)
encode_dxa: Suspect behaviour
| Reported by: | eriktorbjorn | Owned by: | Kirben |
|---|---|---|---|
| Priority: | high | Component: | Tools |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
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...
Ticket imported from: #1504440. Ticket imported from: bugs/2670.
Change History (5)
comment:1 by , 18 years ago
| Owner: | set to |
|---|
comment:2 by , 18 years ago
comment:3 by , 18 years ago
| Priority: | normal → high |
|---|
comment:5 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
| Summary: | TOOLS: Suspect behaviour in encode_dxa → encode_dxa: Suspect behaviour |
Definitely an error with my initial code and a bug.