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: 2009-11-30 07:44:31
Message-ID: e51f66da0911292344k2d98d30dqf60dbf492c52eb48@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2009-11-30 07:45:26 set the cost of an aggregate function
Previous Message rahimeh khodadadi 2009-11-30 07:29:35 Fwd: psql+krb5