Re: [pgsql-hackers-win32] snprintf causes regression tests

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