Messages in this thread | | | From | Jan Kratochvil <> | Subject | Re: problems with compiling 2.1.45-7 | Date | 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
| |