On 12/16/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marko Kreen <markokr@gmail.com> writes:
> > On 12/16/09, Kurt Harriman <harriman@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