* iOS/tvOS: bundle cores as frameworks as opposed to dylibs
* iOS/tvOS: update plist to indicate controller support
* iOS/tvOS: living within the sandbox
* iOS/tvOS: import content through share sheet
* iOS/tvOS: default audio sync off due to crash on background
* iOS/tvOS: don't try altkit if there's no reason to
* iOS/tvOS: enumerate cores for appstore distribution
usage of strlcpy (when position/offset of previous strlcpy/snprintf call
is known. strlcat implementation in libretro-common makes implicit strlen
call, using strlcpy avoids this
* Reduce a bunch of local char variables by use of said clever usage,
should save up on local stack size usage
as deprecated.
* Use fill_pathname_join_special in the vast majority of cases where
we can ensure out_path is a new empty string
* Get rid of some extension concatenation with strlcat where encountered
* Some general cleanups with NULL termination of strings that get immediately
passed to strlcpy/strlcpy-adjacent functions
* (joypad_connection) Small optimizations -
* Turn functions static where possible
* Hose strlen call out of loop
* (input_driver.c) General cleanups:
* Some small code/style nits
task_screenshot.c:
* Move widget callback function for screenshots to task_screenshot.c
(file_path.c):
* Turn get_pathname_num_slashes into static function
* path_linked_list_free - always returns true, so get rid of return value
* path_linked_list_new - fix function signature
* path_get_archive_delim - do not NULL-terminate string, already done by strlcpy later on
General:
* Slight optimizations - use int/size_t for loop counter variable instead of unsigned
* Take advantage of fact that strlcpy already NULL-terminates, so don't do this explicitly
outside if we're just going to end up calling strlcpy/fill_pathname_join on it anyway
and string_list_deinitialize - takes a pointer to initialize
and deinitialize a string list, but importantly does not
implicitly allocate and deallocate the string list pointer
itself. This way, string lists can be put on the stack instead
of always implicitly being put on heap - the struct itself is
small enough to fit on stack
