I’ve noticed that SDL provides implementations of standard library functions in case, for example, they are not available on the host system. Additionally, by using a few macros, it redefines functions like malloc as SDL_malloc, or vice versa, so that the function names with the SDL_ prefix are equivalent to the function names without it.
My question is: when you use stdlib (libc, libm) functions in your SDL programs, do you use the function names with the prefix (e.g. SDL_malloc, SDL_atan, etc.), or those without it (malloc, atan, etc.)? Do you have a reason for your preference? Is one way considered better practice, or more portable than the other?
I’m just reading the source code - regarding the math implements (libm) it seems the philosophy of SDL2 is to provide accurate multiplatform double precision, so if you want maximum compatibility with SDL2s targets, then use them - but if you have only a single target and know the arch and specs, then roll your own approximation. I’d guess that philosophy is similar for the other substitutions - by using them you gain maximal accurate portability without needing to rewrite at cost of some performance hit.
As we can see in this SDL_joystick: Add "translator" joystick driver · libsdl-org/SDL@a252b17 · GitHub build failure, some platform lacks standard C library in SDL build to reduce dependency.
malloc is slightly different story. SDL has
SDL_SetMemoryFunctions to replace it.
Personally, I don’t use
SDL_ prefixed stdlib APIs since my app can depend on standard C library always and let compilers optimize their call (as compiler built-ins).
The SDL stdlib functions are really there to provide consistent C library interface inside of SDL. The most important reason for this is to be completely independent of C runtime on Windows. They are exported for applications to use if they want, but it’s not a complete C stdlib implementation, so you might need more than what is provided.