dump_config_tree() is declared to return an int, but the compiler cannot
prove that it always returns any value at all. This leads to a clang
warning, when building via:
make LLVM=1 -C tools/testing/selftests
Fix this by unconditionally returning the "err" variable if the code
reaches the end of the function.
Signed-off-by: John Hubbard <[email protected]>
---
tools/testing/selftests/alsa/conf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/alsa/conf.c b/tools/testing/selftests/alsa/conf.c
index 89e3656a042d..0109fde53e6f 100644
--- a/tools/testing/selftests/alsa/conf.c
+++ b/tools/testing/selftests/alsa/conf.c
@@ -116,6 +116,8 @@ static int dump_config_tree(snd_config_t *top)
if (snd_config_save(top, out))
ksft_exit_fail_msg("config save\n");
snd_output_close(out);
+
+ return err;
}
snd_config_t *conf_load_from_file(const char *filename)
base-commit: ddb4c3f25b7b95df3d6932db0b379d768a6ebdf7
prerequisite-patch-id: b901ece2a5b78503e2fb5480f20e304d36a0ea27
--
2.45.0
On Fri, May 03, 2024 at 07:13:30PM -0700, John Hubbard wrote:
> dump_config_tree() is declared to return an int, but the compiler cannot
> prove that it always returns any value at all. This leads to a clang
> warning, when building via:
>
> make LLVM=1 -C tools/testing/selftests
>
> Fix this by unconditionally returning the "err" variable if the code
> reaches the end of the function.
Reviewed-by: Mark Brown <[email protected]>
On Fri, May 03, 2024 at 07:13:30PM -0700, John Hubbard wrote:
> dump_config_tree() is declared to return an int, but the compiler cannot
> prove that it always returns any value at all. This leads to a clang
> warning, when building via:
Though given that the function isn't referenced we could also just
delete it.
On 5/5/24 7:53 AM, Mark Brown wrote:
> On Fri, May 03, 2024 at 07:13:30PM -0700, John Hubbard wrote:
>> dump_config_tree() is declared to return an int, but the compiler cannot
>> prove that it always returns any value at all. This leads to a clang
>> warning, when building via:
>
> Though given that the function isn't referenced we could also just
> delete it.
Even better, thanks for spotting that. I'll send a v2 to delete it.
thanks,
--
John Hubbard
NVIDIA