Re: pgsql: Clarify coding of .exe patch - Mailing list pgsql-committers

From Neil Conway
Subject Re: pgsql: Clarify coding of .exe patch
Date
Msg-id 1099291518.17405.102.camel@localhost.localdomain
Whole thread Raw
In response to Re: pgsql: Clarify coding of .exe patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Clarify coding of .exe patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
On Mon, 2004-11-01 at 17:29, Tom Lane wrote:
> I think both you and Bruce are missing the really fundamental point
> here.  You are both optimizing on the grounds that there is no god but
> RMS and his prophet is GCC.  I have a somewhat wider view of which
> compilers we want to target.

:-)

Regarding GCC and its optimization of strlen(), the point I made earlier
is that this is not an idiosyncratic feature of GCC, this is a feature
of essentially *any* modern optimizing compiler.

Regarding __builtin_constant_p(), it is obviously the case that we need
to ensure the code compiles on a wide variety of C compilers. But I
don't see the harm in using GCC-specific features where (a) they can be
easily #ifdef'd away when not using GCC (b) they have a very limited
impact -- i.e. they do not result in using a lot of #ifdefs, or
significantly changing the behavior of the code. Using
__builtin_constant_p() would be a matter of literally 3 lines of code in
a header file somewhere that would not effect correctness, it would
merely serve as a programming tool to catch bugs.

It's one thing to recognize we should keep the code portable across
compilers; it is entirely another to be aware of the fact that the vast
majority of our users and developers use GCC, and to take limited
advantage of GCC features where it is appropriate to do so.

-Neil



pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Clarify coding of .exe patch
Next
From: neilc@svr1.postgresql.org (Neil Conway)
Date:
Subject: pgsql: Trivial fixes for English grammar in contrib/btree_gist and