Alcaro
commented
9 years ago Fixing the ambiguity is a good idea, but not in this way. The comments say
* Can be called at any time, even before retro_init().
and allowing retro_deinit to destroy anything not created by retro_init sounds like a very swift way to create a mess; anything that's valid before retro_init should remain valid after retro_deinit. (I guess whoever wrote that assumed retro_deinit+core unload is an atomic operation.)
While we could say that the core must be initialized to call that function, I see no advantage to that - there are very few, if any at all, reasons to vary anything there depending on anything except the compile flags, and even if there are any, we can put that check in get_system_info. On the other hand, my frontend likes loading all cores it can find, ask what they support, and then unload them without initializing them. I would be displeased if I was forced to initialize them; it will take a fair bit of processor time, dump a pile of stuff to stdout and log_cb, and possibly leak a bit of memory and/or do some other undesirable stuff, too. The info files are not a valid solution - they currently seem to be a complement/cache, and I like that (most) cores are one simple file. Additionally, if we want to make them mandatory, we should remove this function and structure entirely.
Therefore, it's better to leave these pointers valid outside init/deinit.
struct retro_system_info comments require pointers to remain valid until retro_deinit() is called, retro_get_system_info() comments suggest pointers must remain valid even after retro_deinit(). Clarify that pointers may be invalidated after the frontend calls retro_deinit().