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

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group