C API: Why isn't setup.c included in Simulator builds?

I'm unsure if this is better suited for SDK Get Help, but since this post is less of a support request and more of a technical question, I thought I'd ask here:

I'm writing an app for the Playdate partially in C, and I'm including libraries that use malloc, free, and realloc. When targeting the hardware, setup.c (a file from the SDK's buildsupport folder) is automatically included in the binary during compilation, and it remaps those methods to use playdate->system->realloc internally. This is beneficial, as (from what I can gather) the original versions of those methods do not work on the Playdate hardware. It allows the developer to use any of those methods without worrying about compatibility.

However, when targeting the simulator, setup.c isn't included, meaning all calls to malloc, free, and realloc use the system provided methods directly, instead of calling playdate->system->realloc. Normally, you'd use the Playdate API's realloc for all memory allocation, but if you use libraries in your program, then they may be using the system's memory allocation methods instead. As long as memory allocated by playdate->system->realloc isn't freed by the system's free, this shouldn't result in crashes, but more importantly, any memory allocation done through the system methods won't be tracked through the Simulator's 16MB malloc pool.

As I do not yet have hardware, I wanted to replicate the hardware environment as closely as I could. I wanted to make calls to malloc, free, and realloc in the Simulator use the Playdate API's realloc instead of the system methods, so I could ensure that my libraries worked with the Playdate API's memory allocation. I found that adjusting my CMakeLists.txt to include setup.c worked exactly as I had expected: now, calls to malloc, free, and realloc from inside the Simulator use the Playdate API instead, and allocations are reflected in the Simulator's Malloc Log. I'd love to know why this isn't the default, as the outcome seems beneficial. I'm also hoping other developers may find this workaround useful. (edit: See replies. Only works on macOS.)

Please let me know if I made any mistakes, or if I'm misunderstanding the full situation. I'm new to the Playdate and haven't been working with C for long, so I'm just trying to learn as much as I can. Thanks!

2 Likes

We can't redefine newlib functions (malloc, free, etc) on the host OS. It will result in a hard build error on Windows and undefined behavior on other platforms (in my testing it worked on Mac but didn't work on Fedora). While the Playdate OS has its own internal version of malloc/free/realloc so they are mapped only when doing a device build.

2 Likes

I was also wondering about that, thank you for the explanation.

Thanks. I'll note that in my build script.