This commit looks a lot bigger than it really is, I noticed a couple spots where with these issues so I ran a regex to find all possible occurrences and switched all that could be, after manually ensuring it was actually correct
Using sizeof on the buffer (as long as the buffer is a char *array*, not a pointer!!) greatly reduces the chance of something having the wrong size because of a later change to the buffer, notably a couple snprintfs were missed in the UTF_BUFFER_BYTESIZE change
Makes it more clear why all of the buffers are being multiplied by 4
Fix UTF-8 bytesize macro
Before UTF_BUFFER_BYTESIZE(str_width - 10)] would multiply the 10, not the whole number, by UTF_MAX_BYTES_PER_RUNE
Do (rune_count + 1) * 4 in UTF-8 bytesize macro
Fix Resize/Truncate String snprintf size
Before it would break if the last character was multi-byte
When identifying a selected `00000001.sav`, cmac type testing is first attempted for 3DS saves with the **DISA** format. If a 3DS save data is not detected, the search continues at expected offsets for gba vc bottom slots in increasingly larger save sizes. For the GBA VC saves, this only calculates and corrects whichever of the two slots is newer or has the higher counter. There are five additional **CMAC_AGBSAVE_** types to differentiate the different gba save sizes. If a bottom slot was found but determined to be older based on comparing the counter values, the search defaults to **CMAC_AGBSAVE_SD**.
For the save counters, there are two scenarios where the value `00` is considered bigger than `FF` depending which slot has what value. If clarification is required, I will post a diagram at [issue #494](https://github.com/d0k3/GodMode9/issues/494) explaining what is meant by `00` bigger than `FF`.
Please make corrections and improvements to the coding as you see fit in your review. I am not well versed or efficient in the C/C++ programming language.