Re: [dmidecode] Dmidecode 2.6 to be released soon

[Jean Delvare]

Hi Petter,

[Jean Delvare]
> > Oh well, this is the second time a problem is reported with this
> > "inline" (first one being a compilation warning on BeOS, which I got
> > rid of by not using -pedantic anymore).

[Petter Reinholdtsen]
> I believe the problem is the order of the statements.  'inline static
> int' work, 'static inline int' does not.

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].

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?

> 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. From the gcc
manual, I think I understand that the inlining may be discarded due to
technical incompatibilities [1], not for performance reasons.

[1] http://gcc.gnu.org/onlinedocs/gcc/Inline.html

> And functions might be inlined anyway if the
> compiler find that useful, so I suspect the 'inline' part is
> completely useless. :)

According to the gcc manual, arbitrary inlining will not occur unless
either -O3 or -finline-functions is used. As I do not use either in
dmidecode, using the "inline" keyword seemed to make sense.

As a matter of fact, the anchor lookup loop in biosdecode is about three
times slower without the inlining, so I have to assume that the "inline"
keyword indeed makes a difference. Such a speed penalty means it's
probably worth attempting to keep the inlining. If simply reverting the
keywords order does the trick, I'll go with this.

Thanks,
-- 
Jean Delvare