Hello. I'm working on a project in C with the SDK and I was tracking a memory leak I had. I finally found it: I was not freeing the returned collision info's memory. I didn't find any mention of the necessity to release the memory in the documentation as I became owner of the memory area, should be it be listed? (it could have been a static buffer in the library's allocations or something) In retrospective it feels a bit logic as most of the returned dynamic elements in the API are dynamically allocated but it only clicked after a while.
Also, I had a small question about drawText. The len argument helps to draw substrings of the same string, to help with typewriter-like textbox effects, right? Is it allowed to put an invalid number (like INT_MAX or -1) to avoid having to store or compute the whole's string length? It works but I'm not sure I'm just exploiting an undefined behavior that happens to work. No details is given either on this argument.
About your second question, @Dave may be able to answer but I am pretty sure that you will run into a segmentation fault at some point if you give a size larger than your buffer.
So far looks like it's handling it fine, those strings are null-terminated (I'm not playing with sub-strings yet) so I am faithful the function will stop on it but I'm not 100% sure if this was the intended design.
If it's working for you I think it's safe! The printing loop exits when the UTF8 decoder returns 0, it just wasn't clear to me whether that's what happens when it hits the terminating \0 in the string. Sounds like that's the case. (I guess I should step through that in the debugger to verify )
)