[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dmidecode] Dmidecode 2.6 to be released soon

From: Petter Reinholdtsen
Subject: Re: [dmidecode] Dmidecode 2.6 to be released soon
Date: Sat, 19 Feb 2005 10:23:58 +0100
User-agent: Mutt/1.4.1i

[Jean Delvare]
> Ah, OK. That's odd. I've always seen it in the "static inline" order
> (the linux kernel source is full of it, for example). Even the gcc
> manual mentions them in that order at times [1].

It is odd, and wrong.  I was mistaken.  The error occur when compiling
with -ansi, and I didn't notice that the -ansi flag was removed
between compiles.  Using __inline instead of inline, fixes the

> I am also really curious as to why only you hit that problem. Are
> you using a special compiler, or additional compilation flags? Or
> does it happen on an exotic architecture?

I suspect it was my use of -ansi -pedantic.

The autoconf macro AC_C_INLINE try to detect if inline or __inline
should be used, and defines inline to __inline when needed.  Perhaps
you should do something similar?  The problem is that 'inline' in fact
isn't ANSI C.

> > But 'inline' is just a compiler hint, and will be ignored if the
> > compiler find it useful.
> I assume "doesn't find it (the inline hint) useful" here.

Yes, a typo.

> If simply reverting the keywords order does the trick, I'll go with
> this.

I was mistaken.  Swapping the keywords do not solve the problem.
Using __inline does.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]