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 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])