[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4vvfwrtbwcxjx35lfogoiekuq77g5hqxcgskjt6dd6pf7ehg2v@edczy6764cyz>
Date: Thu, 31 Aug 2023 15:02:16 +0200
From: Maciej Wieczór-Retman
<maciej.wieczor-retman@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>
CC: "Yu, Fenghua" <fenghua.yu@...el.com>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
Peter Newman <peternewman@...gle.com>,
"Jonathan Corbet" <corbet@....net>,
Shuah Khan <skhan@...uxfoundation.org>,
"x86@...nel.org" <x86@...nel.org>,
Shaopeng Tan <tan.shaopeng@...itsu.com>,
James Morse <james.morse@....com>,
Jamie Iles <quic_jiles@...cinc.com>,
"Babu Moger" <babu.moger@....com>,
Randy Dunlap <rdunlap@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: Re: [PATCH v5 1/8] x86/resctrl: Prepare for new domain scope
On 2023-08-30 at 14:11:14 +0000, Luck, Tony wrote:
>> >+static int get_domain_id_from_scope(int cpu, enum resctrl_scope scope)
>> >+{
>> >+ switch (scope) {
>> >+ case RESCTRL_L3_CACHE:
>> >+ return get_cpu_cacheinfo_id(cpu, 3);
>> >+ case RESCTRL_L2_CACHE:
>> >+ return get_cpu_cacheinfo_id(cpu, 2);
>> >+ default:
>> >+ WARN_ON_ONCE(1);
>> >+ break;
>> >+ }
>> >+
>> >+ return -1;
>> >+}
>>
>> Is there some reason the "return -1" is outside of the default switch
>> case?
>>
>> Other switch statements in this patch do have returns inside the default
>> case, is this one different in some way?
>
>I've sometimes had compilers complain about code written:
>
>static int get_domain_id_from_scope(int cpu, enum resctrl_scope scope)
>{
> switch (scope) {
> case RESCTRL_L3_CACHE:
> return get_cpu_cacheinfo_id(cpu, 3);
> case RESCTRL_L2_CACHE:
> return get_cpu_cacheinfo_id(cpu, 2);
> default:
> WARN_ON_ONCE(1);
> return -1;
> }
>}
>
>because they failed to notice that every path in the switch does a "return and they
>issue a warning that the function has no return value because they don't realize
>that the end of the function can't be reached.
>
>So it's defensive programming against possible complier issues.
I recall getting that error somewhere while playing around with a
language server protocol for neovim a while ago but I tried to cause
it today with gcc and clang and with some different flags and coulnd't.
Are there some particular compilers or compiler flags that trigger
that?
--
Kind regards
Maciej Wieczór-Retman
Powered by blists - more mailing lists