Skip to content

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 a 9 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.