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
