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
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 |