From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Clarify coding of .exe patch |
Date: | 2004-11-01 05:47:49 |
Message-ID: | 5139.1099288069@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Neil Conway <neilc(at)samurai(dot)com> writes:
> Tom, can you elaborate on why you prefer sizeof()? ISTM that a decent
> compiler will evaluate the strlen() at compile-time if the argument is a
> compile-time constant. GCC will do this (even at -O0!), for example.
sizeof() is defined as a compile-time constant by the C language
specification. strlen() is not a compile-time constant, and in my
judgement a compiler that evaluates it as such is exceeding its
authority. The *linker* could in many cases reduce the call to a
constant with certainty, because it could know whether the function
reference was being resolved to the normal C-library definition or not.
(But it would not have very much scope to do anything with the knowledge
:-(.) gcc's behavior is completely indefensible; it is quite analogous
to my writing some hexadecimal bit-pattern as a substitute for
upper("foo") because I think I know what upper() will behave as.
This is not an argument against our replacing strlen(".exe") by 4
when we know that we intend to invoke a version of strlen() that will
act that way. I am just pointing out that the C compiler has no
business doing this for us; we'd be squawking very loudly if it made
entirely-similar assumptions that we chanced not to like as much.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-11-01 06:17:10 | Re: pgsql: Clarify coding of .exe patch |
Previous Message | Neil Conway | 2004-11-01 05:26:33 | Re: pgsql: Clarify coding of .exe patch |