Use configured key, value, and filename limits while loading and saving settings storage data.
The text backend now builds backup filenames with a sized buffer and bounded formatting, and both text and binary loading reject keys or string values that are not terminated within their configured field sizes. This completes #3109 without changing the storage formats.
Signed-off-by: Nightt <87569709+nightt5879@users.noreply.github.com>
Use strnlen() for public key, value, and storage path length checks so user-provided settings strings are validated against the configured maximum sizes before they are scanned.
Use bounded key comparisons and strlcpy() for fixed-size settings fields. This addresses part of #3109 without changing the settings API or storage formats.
Signed-off-by: Nightt <87569709+nightt5879@users.noreply.github.com>
The settings save path no longer re-enters g_settings.mtx, so the mutex does not need to be initialized as PTHREAD_MUTEX_RECURSIVE.
This keeps the #3105 fix independent of CONFIG_PTHREAD_MUTEX_TYPES and destroys the temporary mutex attribute object after initialization.
Signed-off-by: Nightt <87569709+nightt5879@users.noreply.github.com>
Fix#3105 by making the immediate save path write pending settings while the caller still owns g_settings.mtx instead of calling the timer callback, which locks the same mutex again.
The cached-save timer callback still takes the mutex before using the same locked helper, so asynchronous saves keep their existing synchronization while non-cached saves no longer depend on a recursive mutex.
Signed-off-by: Nightt <87569709+nightt5879@users.noreply.github.com>
* Remove duplicate checks, use switch/case whenever possible
* Remove assertions just before if () condition checking the exact
same thing
* Replace if (condition) assert(0) with assert(condition)
Signed-off-by: Jean THOMAS <jean@lambdaconcept.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
