On 12/16/09, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Marko Kreen <mark...@gmail.com> writes:
> > On 12/16/09, Kurt Harriman <harri...@acm.org> wrote:
>
> >> For gcc, I think the __attribute__ has to come after the function's
> >> parameter list, rather than before the return type.
>
> > No.
>
>
> [ squint... ] That's nowhere documented that I can find: all the
> examples in the gcc docs show __attribute__ after the parameters.
> It does seem to work, but should we rely on it?
Heh. At least in 3.0, 3.1 and 4.2 docs there is:
__attribute__((noreturn)) void d0 (void),
__attribute__((format(printf, 1, 2))) d1 (const char *, ...),
d2 (void);
describing that _att before decl list applies to all declarations,
but _att after decl applies to only that declaration. That sort of
explains also why all examples have _att afterwards.
http://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Attribute-Syntax.html
But I dare not to pick out sentences from Function-Attributes.html
that describe that...
> The bigger problem though is that not all versions of gcc understand
> always_inline:
>
> $ gcc -Wall check.c
> check.c:3: warning: `always_inline' attribute directive ignored
Oh, another argument against logic in headers.
> which I think is sufficient reason to put an end to this sub-thread.
> We have no particular need for force-inline semantics anyway, as
> long as the compiler behaves reasonably for unreferenced inlines,
> which gcc always has.
Ok.
--
marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
