Re: [Fwd: Re: UnixWare 7.1.3 (BETA), C99 compiler, - Mailing list pgsql-hackers

Dave,  Thanks for the details, I've copied this reply back to the PostgreSQL
guys as well. 

LER

On Mon, 2002-10-28 at 09:00, Dave Prosser wrote:
> Larry Rosenman wrote:
> > From: Tom Lane <tgl@sss.pgh.pa.us>
> > To: Larry Rosenman <ler@lerctr.org>
> > Cc: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] UnixWare 7.1.3 (BETA), C99 compiler, current CVS, error...
> > Date: 26 Oct 2002 11:07:13 -0400
> > 
> > Larry Rosenman <ler@lerctr.org> writes:
> > > Without specifying the -Xb switch to kill the C99 interpretation of
> > > inline, I get the following from current CVS:
> > 
> > > UX:acomp: ERROR: "tuplesort.c", line 1854: "inline" functions cannot use
> > > "static" identifier: myFunctionCall2
> > 
> > I don't understand what it's unhappy about.  My C99 draft sez
> > 
> >        [#6] Any function with internal linkage  can  be  an  inline
> >        function.
> > 
> > so the text of the message is surely not what they are really
> > complaining about?  Or is the compiler broken?
> 
> There is a contraint (i.e., a diagnostic is required) in 6.7.4 Function Specifiers
> that says:
> 
>  An inline definition of a function with external linkage shall not contain a
>  definition of a modifiable object with static storage duration, and shall not
>  contain a reference to an identifier with internal linkage.
> 
> Line 1854 is
>     if (DatumGetBool(myFunctionCall2(sortFunction, datum1, datum2)))
> where myFunctionCall2() is a static function defined above ApplySortFunction().
> It's not the inlinedness--a word?--of myFunctionCall2() that's the problem,
> it's that myFunctionCall2() is static and that ApplySortFunction() is inline'd.
> 
> You wrote in your follow up:
> >After reading a little further, it seems that the brain damage is in the
> >standard, not the compiler :-(.  It looks like C99's notion of a
> >function that is both global and inline is that you must provide *two*
> >definitions of the function, one marked inline and one not; moreover,
> >these must appear in separate translation units.  What in the world were
> >those people smoking?  That's a recipe for maintenance problems (edit
> >one definition, forget to edit the other), not to mention completely at
> >variance with the de facto standard behavior of inline that's been
> >around for a long time.
> 
> The C committee's view of inline does not match the historic GCC one.
> They were trying to find a middle ground that was fully compatible with
> the C++ inline, while not requiring any fancy code generation tricks.
> In other words, that C could still be compiled with a one-pass compiler.
> 
> The motivation for this restriction is to make sure that all instances
> of an inline function that's visible outside of the compilation unit
> are identical.  Having the same sequence of tokens isn't good enough
> if there are references to identifiers that could well be different in
> differing compilation units.
> 
> Until the open source base (and GCC) get around to matching the C99
> inline model, I generally attempt to compile open source with "cc -Xb"
> as that eliminates recognition of inline as a keyword, and thus doesn't
> get into the issues with the clashes between the two models.
> 
> >My inclination is to change the code for ApplySortFunction to look like
> >
> >        #if defined(__GNUC__)
> >        __inline__
> >        #endif
> >        int32
> >        ApplySortFunction
> >
> >so that the inline optimization only gets done for gcc, which we know
> >interprets inline sanely.  Anyone see a better answer?
> 
> You've given us one source file.  Is ApplySortFunction() really called
> from other files?  Another approach, assuming both this and that the
> inlining is viewed as important for its three calls within this file,
> to have a front end version of an internal function.  To wit:
> 
> 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)
> {
>     return StaticApplySortFunction(sortFunction, kind, datum1, isNull1, datum2, isNull2);
> }
> 
> and change all the existing calls within tuplesort.c to use
> StaticApplySortFunction().  This approach requires no #ifdef's and
> should have the same effect as the existing source with GCC's view
> of inline.
> 
> -- 
> Dave Prosser   dfp@caldera.com   (908)790-2358   The SCO Group, Murray Hill, NJ
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749