Re: pgsql: Clarify coding of .exe patch

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Clarify coding of .exe patch
Date: 2004-11-01 13:12:05
Message-ID: 200411011312.iA1DC5N29702@candle.pha.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > While I still think we're on pretty solid ground assuming this
> > optimization is going to be made, I'm fine with defining something like
> > const_strlen() that uses sizeof(). Also, we can guard against programmer
> > mistakes via __builtin_constant_p() when using GCC.
>
> 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.

Just to clarify, I am not against the use of sizeof() and I understand
Tom's point. My issue was the use of a constant that doesn't clearly
document.

As I remember the ability of the compiler to evaluate strlen is that if
there is a prototype in scope for strlen() that is somehow different
from the compilers then the compiler can not make the optimization. I
see my BSD using:

size_t strlen __P((const char *));

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Dave Cramer 2004-11-01 13:17:14 pgsql: fixed bug in segfault REVOKE statement
Previous Message Neil Conway 2004-11-01 11:11:14 pgsql: Trivial fixes for English grammar in contrib/btree_gist and