Potential Array OOB
I say potential, because the error doesn't make much sense. This was observed when compiling the v3
demo, but it occurs when compiling the library itself
Crayon-Savefile/libCrayonSavefile/code/savefile.c: In function ‘crayon_savefile_deserialise_savedata’:
Crayon-Savefile/libCrayonSavefile/code/savefile.c:1028:41: warning: array subscript 9 is above array bounds of ‘uint32_t[9]’ {aka ‘long unsigned int[9]’} [-Warray-bounds=]
1028 | pointers[curr->data_type] += curr->data_length;
| ~~~~~~~~^~~~~~~~~~~~~~~~~
Crayon-Savefile/libCrayonSavefile/code/savefile.c:993:26: note: while referencing ‘pointers’
993 | uint32_t pointers[CRAYON_NUM_TYPES] = {0};
| ^~~~~~~~
Crayon-Savefile/libCrayonSavefile/code/savefile.c:1028:41: warning: array subscript 9 is above array bounds of ‘uint32_t[9]’ {aka ‘long unsigned int[9]’} [-Warray-bounds=]
1028 | pointers[curr->data_type] += curr->data_length;
| ~~~~~~~~^~~~~~~~~~~~~~~~~
Crayon-Savefile/libCrayonSavefile/code/savefile.c:993:26: note: while referencing ‘pointers’
993 | uint32_t pointers[CRAYON_NUM_TYPES] = {0};
| ^~~~~~~~
Here's what's weird about it:
- It prints the warning twice, for some reason
- The library itself never sets
data_type
. The only way it could be 9 or more is if the caller did so - If we manually set
CRAYON_NUM_TYPES
to 10, then the error disappears. For some reason, it only complains about a9
value. - If you add a new case to the switch statement above line 1028, and purposely add an OOB, it instead just repeats the existing error two more times...why?
I think my current toolchain might be defective, so this issue needs more research before I can verify if its really an issue or not.