On Mon, Apr 04, 2011 at 09:10:45PM +0200, Alexander Bluhm wrote:
> On Mon, Apr 04, 2011 at 08:06:57PM +0200, Pascal Stumpf wrote:
> > net/pf.c: pf_addr_compare (was probably ok before r1.729)
>
> The current implementation has been discussed. See also:
> http://www.greenend.org.uk/rjk/2003/03/inline.html
Hmm, the second C99 case is interpreted differently by ragge:
http://pcc.ludd.ltu.se/jira/browse/PCC-287
>
> The function should be inline within pf.c and callable from pf_norm.c.
> Defining it inline in pf.c allows faster code there, declaring it
> non-inline in pfvar.h creates callable code in pf.o. gcc always
> generates callable code, so it does not matter here.
>
> Do pcc and clang compile and link if you put an inline in the pfvar.h
> declaration?
No, because it still isn't extern. Both the declaration in pfvar.h and
the definition in pf.c need "extern __inline" for it to compile and link
with pcc. But that breaks gcc. And gcc doesn't support C99 inline
functions (with -std=c99). So, to provide compatibility with both C99
and GNU, one would have to do that macro hack at the bottom of the page.
Anyway, if pcc behaviour was changed so that
extern inline void foo();
inline void
foo()
{
}
created external linkage, it would be much easier to be compatible to
both.
>
> > Do those *have* to be inline?
>
> Yes, pf_addr_compare() is used in pf state lookup. So it must be
> fast. The generated RB functions use it inline.
>
> bluhm
