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

Magnus Hagander wrote:
> > 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.
> >
> > 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?
> >
> > Third thought: Windows' linker seems to be broken enough that
> > it may create problems of this ilk that exist on no other platform.
>
> If you're takling the combination of libpq and Windows, we are definitly
> safe for dynamic linking, which is what most ppl will use. Because the
> DLL will only export the entrypoitns that we explicitly define in the
> DEF files, and those are also the only ones that are present in the
> "import library".

Right.  It is Unix that has the problem.  It seems we are supplying a
special snprintf() only so gettext() in libintl will use ours instead of
the operating system's.  Isn't there a way to target just that library
for our replacement snprintf()?  Our code itself doesn't need the
positional parameters.

Could we read the snprintf translation string and process positional
parameters _before_ we sent it to gettext()?

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