linux-kernel - Re: [2.6 patch] parisc: "extern inline" -> "static inline" (fwd)

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]

Date:	Fri, 1 Dec 2006 17:54:27 +0100
From:	Adrian Bunk <bunk@...sta.de>
To:	Grant Grundler <grundler@...isc-linux.org>
Cc:	Andrew Morton <akpm@...l.org>, matthew@....cx,
	kyle@...isc-linux.org, parisc-linux@...isc-linux.org,
	linux-kernel@...r.kernel.org
Subject: Re: [2.6 patch] parisc: "extern inline" -> "static inline" (fwd)

On Fri, Dec 01, 2006 at 09:43:54AM -0700, Grant Grundler wrote:
> On Fri, Dec 01, 2006 at 12:48:11PM +0100, Adrian Bunk wrote:
> > "extern inline" generates a warning with -Wmissing-prototypes and I'm 
> > currently working on getting the kernel cleaned up for adding this to 
> > the CFLAGS since it will help us to avoid a nasty class of runtime 
> > errors.
> 
> 
> John David Anglin is the hppa/parisc gcc maintainer and has
> commented on inline variants last year:
>     http://lists.parisc-linux.org/pipermail/parisc-linux/2005-October/027587.html
> 
> This makes me think -Wmissing-prototypes is reporting the wrong warning.
> ie there is a prototype but no function and no label.
> Can you check with gcc folks to see if this is a gcc bug?
> 
> The parisc point intentionally switched to "extern inline" at one
> point and unless what jda wrote is now incorrect, I'm not inclined
> to change it.

If you read John David Anglin's email, you'll note that if you take the 
address you need this function provided somewhere.

Which of the functions my patch changes also have a global function 
provided within the kernel?

If none, "extern inline" didn't make any sense.

> > If there are places that really need a forced inline, __always_inline 
> > would be the correct solution.
> 
> Yes, all the functions marked "extern inline" are expected to get
> essentially the same treatment as "always_inline".

Currently, "inline" is defined to be always_inline, and 
__always_inline is for cases that produce non-compiling or non-working 
(opposed to only suboptimal) code.

> thanks,
> grant

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/