Re: pgsql: Clarify coding of .exe patch

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: pgsql: Clarify coding of .exe patch
Дата
Msg-id 1099289830.17405.60.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 16:47, Tom Lane wrote:
> 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.

Well, I suppose it's a little weird, yes. Per my reading of C99
(5.1.2.3), this optimization is not disallowed by the standard. Also,
GCC is hardly the only compiler that does this: the use of compiler
instrinsics to implement various libc functions (e.g. memset, math
functions, and so on) is quite widespread.

> 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.

(FWIW GCC does the strlen() optimization before invoking the linker.) In
any case, wouldn't this still be broken in the presence of LD_PRELOAD?

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.

-Neil



В списке pgsql-committers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Clarify coding of .exe patch
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Clarify coding of .exe patch