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