Обсуждение: Sun Studio compiler warnings

Sun Studio is producing these compiler warnings (among others):

"tsquery_op.c", line 193: warning: syntax error:  empty declaration 
"tsquery_op.c", line 194: warning: syntax error:  empty declaration 
"tsquery_op.c", line 195: warning: syntax error:  empty declaration 
"tsquery_op.c", line 196: warning: syntax error:  empty declaration 
"tsquery_op.c", line 197: warning: syntax error:  empty declaration 
"tsquery_op.c", line 198: warning: syntax error:  empty declaration

"tsvector_op.c", line 177: warning: syntax error:  empty declaration 
"tsvector_op.c", line 178: warning: syntax error:  empty declaration 
"tsvector_op.c", line 179: warning: syntax error:  empty declaration 
"tsvector_op.c", line 180: warning: syntax error:  empty declaration 
"tsvector_op.c", line 181: warning: syntax error:  empty declaration 
"tsvector_op.c", line 182: warning: syntax error:  empty declaration 
"tsvector_op.c", line 183: warning: syntax error:  empty declaration

This relates to the following sort of code:

#define CMPFUNC( NAME, CONDITION )              \
Datum                                           \
NAME(PG_FUNCTION_ARGS) {                        \    TSQuery  a = PG_GETARG_TSQUERY_COPY(0);     \    TSQuery  b =
PG_GETARG_TSQUERY_COPY(1);    \    int res = CompareTSQ(a,b);                  \
       \    PG_FREE_IF_COPY(a,0);                       \    PG_FREE_IF_COPY(b,1);                       \
                                 \    PG_RETURN_BOOL( CONDITION );                \
 
}

CMPFUNC(tsquery_lt, res < 0);
CMPFUNC(tsquery_le, res <= 0);
CMPFUNC(tsquery_eq, res == 0);
CMPFUNC(tsquery_ge, res >= 0);
CMPFUNC(tsquery_gt, res > 0);
CMPFUNC(tsquery_ne, res != 0);

The closing semicolon is strictly speaking not allowed here.  We could 
remove it, but that would probably upset pgindent?

I recall that we used to have a bunch of similar problems with the AIX 
compilers a long time ago.  Does anyone recall the solution, and do we 
still care?  (Note that it's only a warning in this case.)

Peter Eisentraut <peter_e@gmx.net> writes:
> CMPFUNC(tsquery_lt, res < 0);
> CMPFUNC(tsquery_le, res <= 0);
> CMPFUNC(tsquery_eq, res == 0);
> CMPFUNC(tsquery_ge, res >= 0);
> CMPFUNC(tsquery_gt, res > 0);
> CMPFUNC(tsquery_ne, res != 0);

> The closing semicolon is strictly speaking not allowed here.  We could 
> remove it, but that would probably upset pgindent?

If the warnings annoy you, do what PG_FUNCTION_INFO_V1 does.

#define PG_FUNCTION_INFO_V1(funcname) \
extern PGDLLIMPORT const Pg_finfo_record * CppConcat(pg_finfo_,funcname)(void); \
const Pg_finfo_record * \
CppConcat(pg_finfo_,funcname) (void) \
{ \static const Pg_finfo_record my_finfo = { 1 }; \return &my_finfo; \
} \
extern int no_such_variable

        regards, tom lane

> The closing semicolon is strictly speaking not allowed here.  We could
> remove it, but that would probably upset pgindent?
>
> I recall that we used to have a bunch of similar problems with the AIX
> compilers a long time ago.  Does anyone recall the solution, and do we still
> care?  (Note that it's only a warning in this case.)

How about the good old

do {
...
} while (0)

trick?

...Robert

Robert Haas escribió:
> > The closing semicolon is strictly speaking not allowed here.  We could
> > remove it, but that would probably upset pgindent?
> >
> > I recall that we used to have a bunch of similar problems with the AIX
> > compilers a long time ago.  Does anyone recall the solution, and do we still
> > care?  (Note that it's only a warning in this case.)
> 
> How about the good old
> 
> do {
> ...
> } while (0)
> 
> trick?

That can't be used because the macro is defining a completely new
function.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Ooooh.... yeah.  Time for some caffeine.

...Robert

On Thu, Oct 30, 2008 at 9:34 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Robert Haas escribió:
>> > The closing semicolon is strictly speaking not allowed here.  We could
>> > remove it, but that would probably upset pgindent?
>> >
>> > I recall that we used to have a bunch of similar problems with the AIX
>> > compilers a long time ago.  Does anyone recall the solution, and do we still
>> > care?  (Note that it's only a warning in this case.)
>>
>> How about the good old
>>
>> do {
>> ...
>> } while (0)
>>
>> trick?
>
> That can't be used because the macro is defining a completely new
> function.
>
> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>