Re: pgsql: Clarify coding of .exe patch

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: pgsql: Clarify coding of .exe patch
Дата
Msg-id 1099291518.17405.102.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: pgsql: Clarify coding of .exe patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pgsql: Clarify coding of .exe patch
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Clarify coding of .exe patch
Следующее
От: neilc@svr1.postgresql.org (Neil Conway)
Дата:
Сообщение: pgsql: Trivial fixes for English grammar in contrib/btree_gist and