Magnus Hagander wrote:
> > Hmm ...
> > 
> > First line of thought: we surely must not insert a snprintf 
> > into 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                        |               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to