Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

Re: Patch: Remove gcc dependency in definition of inline functions


  • From: Marko Kreen <markokr(at)gmail(dot)com>
  • To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • Cc: Kurt Harriman <harriman(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: Patch: Remove gcc dependency in definition of inline functions
  • Date: Mon, 30 Nov 2009 09:44:31 +0200
  • Message-id: <e51f66da0911292344k2d98d30dqf60dbf492c52eb48@mail.gmail.com> <text/plain>

On 11/29/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kurt Harriman <harriman(at)acm(dot)org> writes:
>  > (Does anybody still use a C compiler that doesn't support
>  > inline functions?)

+1 for modern C.

> The question isn't so much that, it's whether the compiler supports
>  inline functions with the same behavior as gcc.  At minimum that
>  would require
>         * not generating extra copies of the function
>         * not whining about unreferenced static functions
>  How many compilers have you tested this patch against?  Which ones
>  does it actually offer any benefit for?

Those are not correctness problems.  Compilers with non-optimal or
missing 'inline' do belong together with compilers without working int64.
We may spend some effort to be able to compile on them, but they
should not affect our coding style.

'static inline' is superior to macros because of type-safety and
side-effects avoidance.  I'd suggest event removing any HAVE_INLINE
ifdefs and let autoconf undef the 'inline' if needed.  Less duplicated
code to maintain.  The existence of compilers in active use without
working 'inline' seems quite hypothetical these days.

-- 
marko



Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group