Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Have we considered what is going to happen to applications when they use
> > our snprintf instead of the one from the operating system?
>
> Hmm ...
>
> First line of thought: we surely must not insert a snprintf into
> libpq.so unless it is 100% up to spec *and* has no performance issues
> ... neither of which can be claimed of the CVS-tip version.
Agreed, and we have to support all the 64-bit specifications a port
might support like %qd and %I64d as well as %lld. I have added that to
our current CVS version.
> Second line of thought: libpq already feels free to insert allegedly
> up-to-spec versions of a number of things, and no one has complained.
> Maybe the linker prevents problems by not linking these versions to
> any calls from outside libpq?
I just tested on BSD/OS and a program with a single printf() call does
call our printf if libpq is used on the link line. The program makes no
libpq calls at all.
> Third thought: Windows' linker seems to be broken enough that it may
> create problems of this ilk that exist on no other platform.
Yes, strangly the Window's linker is fine because libpqdll.def defines
what symbols are exported. I don't think Unix has that capability.
Is there any way we can have just gettext() call our snprintf under a
special name?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
