one - if you set the last parameter to a valid 'rarch_setting_t' pointer
and enum_msg to MSG_UNKNOWN, you will get the previous menu_entries_append
behavior
* Renamed remaining function to menu_entries_append so that we have one
consistent way of adding menu entries instead of two
Reduces some code duplication significantly
(menu_displaylist.c) Some optimizations:
* Make sure val_d is never bigger than 16, it should just
contain a number. 16 is more than plenty (and probably too big even)
* Hose val_d out of loops if its value never changes inside the loop
* Attempt to avoid calling msg_hash_to_str inside loops unnecessarily
* Don't attempt to call msg_hash_to_str in a loop, cache it once outside
inside a local variable
* Do away with some spurious snprintf usage for RGUI (truncation does not matter
as pointed out by jdgleaver, so we needn't be concerned)
(snprintf) Try to reduce or simplify snprintf calls, only tend to
use it for processing integers/numbers and avoid it for regular
string concatenation (NOTE: we try to be a bit safer about it to
address earlier cited criticism, although we don't consider concatenating
3 or 4 characters at the end to be insecure)
(msg_hash_to_str) Try to avoid duplicate calls to the same localized
string when we can just cache the results once instead locally
Avoids the internal strlen call inside strdup, and strdup is a deprecated
function starting from MSVC2005 anyways.
NOTE: Do NOT pass STRLEN_CONST as n parameter to strldup, it needs to
be at least +1 character higher than the strlen return value of the same
string
Reasons:
1 - Just a macro for strcpy
1.2 - doesn't have a return type unlike strlcpy, can't be used
for string concatenation
1.3 - unsafe compared to strlcpy
Do either manual string assignment per character or strlcpy, no
inbetween by resorting to strcpy
(retroarch.c) retroarch_get_capabilities - get rid of strlcat
party in RARCH_CAPABILITIES_CPU, do simple manual assignment for
concatenation instead and NULL terminate at the end
(menu_displaylist.c) Do something about some of the unnecessarily huge
local strings of PATH_MAX_LENGTH size (can be as large as 8192)
(menu_displaylist.c) Replace some trivial strlcats / snprintfs
(D3D10/D3D11/D3D12) Strings don't need to be initialized -
strlcpy already null-terminates - get rid of some constants
- (database_info.c) Optimizations for database_info_build_query_enum() -
it would call strlcat at the very least 3 times, normally more than that.
Every strlcat call is at least one or more strlens. Reduce it all down
to manual string concatenation and one strlcat
- (database_info_build_query_enum) - always NULL terminates string so no need for NULL termination done by callee
* (menu_displaylist) use smaller strings for basename paths, remove one unnecessary string
in menu_displaylist.c function
- (disk_index_file.c) Avoid another trivial string concatenation by doing
it manually after fill_pathname_join_special
- (fill_pathname_join_delim) since fill_pathname_join_delim() now has a return value, use it for
string concatenation
- (platform_unix) - Use BUFSIZ as size for a buffer in system_property_get
- some other trivial strlcat usage replacements
(menu_contentless_cores) Fix mistake - needed to set len to return
value of fill_pathname_join_special
(configuration.c) Fix some unused variable warnings on Linux
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
