linux-kernel - Re: [PATCH] m68k: atari: Make Atari ROM port I/O write macros return void

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e253a579-1388-7c23-6425-13b692815a38@roeck-us.net>
Date:   Fri, 20 May 2022 08:52:22 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kernel test robot <lkp@...el.com>
Subject: Re: [PATCH] m68k: atari: Make Atari ROM port I/O write macros return
 void

On 5/20/22 08:07, Geert Uytterhoeven wrote:
> Hi Günter,
> 
> On Fri, May 20, 2022 at 4:52 PM Guenter Roeck <linux@...ck-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@...el.com>
>>> Reported-by: Guenter Roeck <linux@...ck-us.net>
>>> Signed-off-by: Geert Uytterhoeven <geert@...ux-m68k.org>
>>
>> Reviewed-by: Guenter Roeck <linux@...ck-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)