Re: pgsql: Clarify coding of .exe patch - Mailing list pgsql-committers

From Neil Conway
Subject Re: pgsql: Clarify coding of .exe patch
Date
Msg-id 1099289830.17405.60.camel@localhost.localdomain
Whole thread Raw
In response to Re: pgsql: Clarify coding of .exe patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Clarify coding of .exe patch
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Clarify coding of .exe patch
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Clarify coding of .exe patch