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 [EMAIL PROTECTED]
To: Larry Rosenman [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] UnixWare 7.1.3 (BETA), C99 compiler, current CVS, error...
Date: 26 Oct 2002 11:07:13 -0400
Larry Rosenman [EMAIL PROTECTED] 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 [EMAIL PROTECTED] (908)790-2358 The SCO Group, Murray Hill, NJ
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
