Re: problems with compiling 2.1.45-7

Jan Kratochvil (short@k332.feld.cvut.cz)
Thu, 17 Jul 1997 10:32:01 +0200 (MET DST)


> At 10:13 AM 7/16/97 -0400, Bill Hawes wrote:
> >Joseph Skinner wrote:
> >Here's the patch I used ...
> >
> >-Bill--- include/linux/dcache.h.old Wed Jul 16 06:44:08 1997
> >+++ include/linux/dcache.h Wed Jul 16 08:59:45 1997
> >@@ -65,7 +65,7 @@
> > * to invalidate a dentry for some reason (NFS
> > * timeouts or autofs deletes).
> > */
> >-inline void d_drop(struct dentry * dentry)
> >+static inline void d_drop(struct dentry * dentry)
> > {
> > list_del(&dentry->d_hash);
> > INIT_LIST_HEAD(&dentry->d_hash);
>
> Doesn't that mean that for a given parameter then the fn will always return
> the same val, and that it has no side-effects, which is totally false here?

No, "static" means that no references will be made to this object outside
the scope of current file - GCC will not emit this symbol to object file's
symbol table and also is able to completely inline this function to all
it's callers without any extra implementation.

The meaning you described is accomplished by __CONSTVALUE macro which
really isn't what we need here! :-)

Someone else also asked why I (or even somebody else - I don't remember)
used "static inline" instead of "extern inline". Reason is simple - I think
that this is the logical way.

"static inline" will never emit this symbol, so no conflicts can appear
and also the compiler is almost forced to do inlining ("inline" directive,
"-finline-functions" and short body).

On the other hand "extern inline" behaves differently depending on whether
the compiler decided to inline it:
a) HAVE inlined - okay, no symbol emitted, this is identical to
"static inline"
b) HAVEN'T inlined - this is identical to specify "extern" without the
included function's body. Generates "undefined" reference and thus needs
additional definition outside this file. WHY TO USE THIS?

I haven't any system in it, but in current kernel are used both methods.
Hope that someone other with more knowledge of GCC will enlight it (at least
for me), although it probably belongs rather to GCC (or C-newbie) mailing list.

Jan "Lace" Kratochvil