Tom Lane wrote:
> >> static inline int32
> >> StaticApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
> >> Datum datum1, bool isNull1,
> >> Datum datum2, bool isNull2)
> >> {
> >> //etc.
> >> }
> >>
> >> int32
> >> ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
> >> Datum datum1, bool isNull1,
> >> Datum datum2, bool isNull2)
>
> Grumble. I suppose we have to do it that way, but it's really pretty
> stupid. Also, won't this fall foul of the original restriction
> (ApplySortFunction referencing the static function myFunctionCall2)?
> If not, why not?
The change is that the inline function referencing the identifiers with
internal linkage also has internal linkage -- i.e., they're both static.
Since there can be only one definition of StaticApplySortFunction(),
there's no reason to restrict it's contents.
> > Until the open source base (and GCC) get around to matching the C99
> > inline model,
>
> Don't hold your breath... it looks like a net loss in functionality
> for no gain, from where I sit.
The GCC owners are now much more standards-aware and -driven than they
were 10+ years ago. I believe that they are going to (if not already)
have a way of interpreting "inline" according to the C99 standard. It
will probably not be the default, given the incompatibilities, but it'll
be there, somehow, sometime.
As far as I'm concerned, the C99 inline doesn't do "me" much good either,
as I cannot use it in headers to take the place of function-like macros
in standard headers, either. But, this is what you get with Committees--
specifications that make everyone unhappy at roughly equivalent levels. :-)
Since "inline" (as specified in C99) is pretty much just a hint to the
compiler in much the same way that "register" was in the good old days,
it really shouldn't matter too much one way or another, but feel free
to use it as you desire.
--
Dave Prosser dfp@caldera.com (908)790-2358 The SCO Group, Murray Hill, NJ
