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
Furthermore, Mark Brown noticed that dump_config_tree() isn't even used
anymore, so just delete the entire function.
Cc: Mark Brown <[email protected]>
Signed-off-by: John Hubbard <[email protected]>
---
tools/testing/selftests/alsa/conf.c | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/tools/testing/selftests/alsa/conf.c b/tools/testing/selftests/alsa/conf.c
index 89e3656a042d..357561c1759b 100644
--- a/tools/testing/selftests/alsa/conf.c
+++ b/tools/testing/selftests/alsa/conf.c
@@ -105,19 +105,6 @@ static struct card_cfg_data *conf_data_by_card(int card, bool msg)
return NULL;
}
-static int dump_config_tree(snd_config_t *top)
-{
- snd_output_t *out;
- int err;
-
- err = snd_output_stdio_attach(&out, stdout, 0);
- if (err < 0)
- ksft_exit_fail_msg("stdout attach\n");
- if (snd_config_save(top, out))
- ksft_exit_fail_msg("config save\n");
- snd_output_close(out);
-}
-
snd_config_t *conf_load_from_file(const char *filename)
{
snd_config_t *dst;
base-commit: f462ae0edd3703edd6f22fe41d336369c38b884b
prerequisite-patch-id: b901ece2a5b78503e2fb5480f20e304d36a0ea27
--
2.45.0
On Sun, May 05, 2024 at 02:08:24PM -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:
Reviewed-by: Mark Brown <[email protected]>
On Sun, 05 May 2024 23:08:24 +0200,
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
>
> Furthermore, Mark Brown noticed that dump_config_tree() isn't even used
> anymore, so just delete the entire function.
>
> Cc: Mark Brown <[email protected]>
> Signed-off-by: John Hubbard <[email protected]>
Thanks, applied now.
Takashi
On 06. 05. 24 9:19, Takashi Iwai wrote:
> On Sun, 05 May 2024 23:08:24 +0200,
> 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
>>
>> Furthermore, Mark Brown noticed that dump_config_tree() isn't even used
>> anymore, so just delete the entire function.
>>
>> Cc: Mark Brown <[email protected]>
>> Signed-off-by: John Hubbard <[email protected]>
>
> Thanks, applied now.
This function is nice for debugging. I'd prefer to keep it with the fix.
Jaroslav
--
Jaroslav Kysela <[email protected]>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
On Mon, 06 May 2024 09:27:38 +0200,
Jaroslav Kysela wrote:
>
> On 06. 05. 24 9:19, Takashi Iwai wrote:
> > On Sun, 05 May 2024 23:08:24 +0200,
> > 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
> >>
> >> Furthermore, Mark Brown noticed that dump_config_tree() isn't even used
> >> anymore, so just delete the entire function.
> >>
> >> Cc: Mark Brown <[email protected]>
> >> Signed-off-by: John Hubbard <[email protected]>
> >
> > Thanks, applied now.
>
> This function is nice for debugging. I'd prefer to keep it with the fix.
I'm find in either way; just submit a fix patch, then.
thanks,
Takashi
On Mon, May 06, 2024 at 09:45:21AM +0200, Takashi Iwai wrote:
> Jaroslav Kysela wrote:
> > This function is nice for debugging. I'd prefer to keep it with the fix.
> I'm find in either way; just submit a fix patch, then.
The fix was already submitted as v1, I noticed that the function was
unused in review.
On 5/6/24 7:44 AM, Mark Brown wrote:
> On Mon, May 06, 2024 at 09:45:21AM +0200, Takashi Iwai wrote:
>> Jaroslav Kysela wrote:
>
>>> This function is nice for debugging. I'd prefer to keep it with the fix.
>
>> I'm find in either way; just submit a fix patch, then.
>
> The fix was already submitted as v1, I noticed that the function was
> unused in review.
It's generally considered a best practice to delete unused code. If
there is something you especially like for upcoming code, you still
have git history, and even a lore.kernel.org link, to bookmark it.
So I'd recommend going with v2, but of course it's your call! :)
thanks,
--
John Hubbard
NVIDIA