On 04/23/2013 09:20 AM, Kenneth Graunke wrote:
On 04/22/2013 09:17 PM, Ian Romanick wrote:
On 04/23/2013 02:39 AM, Kenneth Graunke wrote:
Otherwise, the table could be full of uninitialized garbage. That means
the NULL check at the bottom might not happen, so we wouldn't get the
_mesa_problem, and we'd then return garbage.
format_pack.c also has tables like this and memsets them.
This *CANNOT* be the right fix. This just papers over things. There
are a lot of entries in the table that are not initialized when several
similar entries are initialized. For example, *ONE* of the ETC2 entries
is missing. Many of the integer formats are present, but some are
missing. Etc.
Fine. I sent out patches to add/fix the rest of the unpack functions.
I didn't mean to be so grumpy in my reply. The jet lag is killing me...
I only got about 3 hours of sleep last night. :(
It still seems like we ought to memset() it so that if someone misses a
new format in the future, they'll hit the _mesa_problem(). And then add
an assertion...
Or perhaps just add a static assert in this code that MESA_FORMAT_COUNT
is a particular value, so if people add a new format, they have to add
unpack code.
Adding a memset and a unit test that verifies that only entry 0 is NULL
ought to make things future proof...
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
