On Thu, May 14, 2020 at 7:05 AM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
>
> But then it's re-declared as not inline.
>
> Could Sparse print a warning for that?
I actually think that would be a bug.
Having a non-inline declaration for an inline function sounds normal
and correct and even expected. I'd not be surprised at all if a
function is declared in a header file as non-inline (because there it
is), but then in the implementation it's defined as inline (because
later uses in that same file might want to inline it).
So warning about inline/non-inline differences is I think actively wrong.
HOWEVER.
In this case I wonder if the real difference is that first we have a
"static" definition of the symbol, and then later there's a non-static
declaration of it. That, to me, smells a bit odd - one has file scope,
the other has external scope, and particularly with the external scope
coming _after_ the file scope, which version of that same symbol does
a subsequent use then use?
Because a static symbol and a symbol with external linkage are clearly
not the same symbol. It's perfectly fine to have an external symbol
'x' that is shadowed by a static symbol 'x' in file scope.
But I wonder if smatch sees the *external* symbol nvme_put_ctrl()
(which doesn't have an inline definition!) rather than the static one
(which does!) because the external declaration comes after the static
definition.
So _that_ might be worth warning about: seeing an external declaration
after a static one makes for confusion.
I'm not sure that is the problem here.
Linus
