Michael Matz wrote:
As "extern inline" is a GNU extension I don't understand this remark.
Sort of.
C99 has the equivalent construct, but spell it differently:
inline foo(int bar) {
...
}
extern foo(int bar);
There is no "static inline" in C99 either; it's just "inline".
-
On Tuesday 06 September 2005 22:55, Terrence Miller wrote:
> Andi Kleen wrote:
> > I don't think the functionality of having single copies in case
> > an out of line version was needed was ever required by the Linux kernel.
>
> But shouldn't the compiler that compiles Linux be C99 compliant?
At le
Hi,
On Tue, 6 Sep 2005, Terrence Miller wrote:
> Andi Kleen wrote:
> > I don't think the functionality of having single copies in case
> > an out of line version was needed was ever required by the Linux kernel.
>
> But shouldn't the compiler that compiles Linux be C99 compliant?
As "extern in
Andi Kleen wrote:
> I don't think the functionality of having single copies in case
> an out of line version was needed was ever required by the Linux kernel.
But shouldn't the compiler that compiles Linux be C99 compliant?
> extern inline was used in the kernel a long time ago as a "poor man's
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 6 Sep 2005 22:23:50 +0200
> I don't think the functionality of having single copies in case
> an out of line version was needed was ever required by the Linux kernel.
Alpha does, exactly for the kind of case this gcc inlining feature was
designed f
I don't think the functionality of having single copies in case
an out of line version was needed was ever required by the Linux kernel.
extern inline was used in the kernel a long time ago as a "poor man's
-Winline". Basically the intention was to get an linker error
if the inlining didn't wo
Jakub Jelinek wrote:
> On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
>
>>It isn't the same, but "static inline" is the correct variant.
>>
>>"extern inline __attribute__((always_inline))" (which is what
>>"extern inline" is expanded to) doesn't make sense.
>
>
> It does make sense
Followup to: <[EMAIL PROTECTED]>
By author:Adrian Bunk <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Mon, Sep 05, 2005 at 02:47:40PM -0400, Jakub Jelinek wrote:
> > On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
> > > It isn't the same, but "static inline" is the corr
On Friday 02 September 2005 22:31, Adrian Bunk wrote:
> "extern inline" doesn't make much sense.
>
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Thanks applied (with a better description)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
On Mon, Sep 05, 2005 at 02:47:40PM -0400, Jakub Jelinek wrote:
> On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
> > It isn't the same, but "static inline" is the correct variant.
> >
> > "extern inline __attribute__((always_inline))" (which is what
> > "extern inline" is expanded to)
On Mon, Sep 05, 2005 at 08:00:05PM +0200, Adrian Bunk wrote:
> It isn't the same, but "static inline" is the correct variant.
>
> "extern inline __attribute__((always_inline))" (which is what
> "extern inline" is expanded to) doesn't make sense.
It does make sense and is different from
static inl
On Mon, Sep 05, 2005 at 10:52:47AM +0200, Michael Matz wrote:
> Hi,
>
> On Fri, 2 Sep 2005, Adrian Bunk wrote:
>
> > "extern inline" doesn't make much sense.
>
> It does. It's a GCC extension which says "never ever emit an out-of-line
> version of this function, not even if its address is taken
Hi,
On Fri, 2 Sep 2005, Adrian Bunk wrote:
> "extern inline" doesn't make much sense.
It does. It's a GCC extension which says "never ever emit an out-of-line
version of this function, not even if its address is taken", i.e. it's
implicitely assumed, that if there is a need for such out-of-line
13 matches
Mail list logo
