UnixWare 7.1.3 (BETA), C99 compiler, current CVS, error...

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?

regards, tom lane

On Sat, 2002-10-26 at 10:07, Tom Lane wrote:

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?

I'll ask, it is Beta (although the Compiler has done this since the C99
functionality was added, and it causes a LOT of open source stuff to
require -Xb).

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
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

Larry Rosenman <ler@lerctr.org> writes:

so the text of the message is surely not what they are really
complaining about? Or is the compiler broken?

I'll ask, it is Beta (although the Compiler has done this since the C99
functionality was added, and it causes a LOT of open source stuff to
require -Xb).

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.

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?

regards, tom lane