Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Sender: Guenter Roeck <groeck7@gmail.com>
Message-ID: <e253a579-1388-7c23-6425-13b692815a38@roeck-us.net>
Date:   Fri, 20 May 2022 08:52:22 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Content-Language: en-US
To:     Geert Uytterhoeven <geert@linux-m68k.org>
Cc:     linux-m68k <linux-m68k@lists.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        kernel test robot <lkp@intel.com>
References: <c15bedc83d90a14fffcd5b1b6bfb32b8a80282c5.1653057096.git.geert@linux-m68k.org>
 <286a1eef-e857-a31f-839b-00a4c835dfa9@roeck-us.net>
 <CAMuHMdX3EYrGPPUEZ3_YPyr6zHnV-xEW3mYB_QyFYaqg_grF-w@mail.gmail.com>
From:   Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH] m68k: atari: Make Atari ROM port I/O write macros return
 void
In-Reply-To: <CAMuHMdX3EYrGPPUEZ3_YPyr6zHnV-xEW3mYB_QyFYaqg_grF-w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 5/20/22 08:07, Geert Uytterhoeven wrote:
> Hi Günter,
> 
> On Fri, May 20, 2022 at 4:52 PM Guenter Roeck <linux@roeck-us.net> wrote:
>> On 5/20/22 07:32, Geert Uytterhoeven wrote:
>>> The macros implementing Atari ROM port I/O writes do not cast away their
>>> output, unlike similar implementations for other I/O buses.
>>> When they are combined using conditional expressions in the definitions of
>>> outb() and friends, this triggers sparse warnings like:
>>>
>>>       drivers/net/appletalk/cops.c:382:17: error: incompatible types in conditional expression (different base types):
>>>       drivers/net/appletalk/cops.c:382:17:    unsigned char
>>>       drivers/net/appletalk/cops.c:382:17:    void
>>>
>>> Fix this by adding casts to "void".
>>>
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Reported-by: Guenter Roeck <linux@roeck-us.net>
>>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>
>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> 
> Thanks!
> 
>>> Removing the casts instead causes issues with functions propagating void
>>> return values (return expression in void function), which BTW sparse
>>> complains about, too.
>>
>> We live and learn. I didn't even know that this was valid syntax.
> 
> I knew about the syntax, but didn't realize immediately why it was
> done that way.
> 
> Initially I thought it was some relic from the "always cast to void
> to make it clear you do not care about the return value"-frenzy, which
> are inside Linux visible mostly in the various "(void)acpi_<foo>(...);"
> calls.  AFAIK these are checked by some external tools.
> In Linux, we have __must_check to annotate the important cases.
> 

I looked at the output of my coccinelle script. To me it looks like
(almost ?) all of the code with "return f(...)" in a function returning
void is just sloppy programming.

In case someone is interested, I attached the script I used below.

Guenter

---
virtual report

@d@
function f;
expression e;
position p;
@@

void f(...)
{
     <...
     return e@p;
     ...>
}

@script:python depends on report@
p << d.p;
f << d.f;
e << d.e;
@@

print "Return in void function %s() at %s:%s: %s" % (f, p[0].file, p[0].line, e)