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".
Advertising
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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
