On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
I have applied a modified version of your patch, attached.
I am so sorry, I sent untested patch again. Thank you very
much for patience in fixing it. The patch looks perfectly
fine and works under Solaris.
Nicolai Tufar wrote:
On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
I have applied a modified version of your patch, attached.
Here is a patch that fixes the %*$ case.
FYI, I am going to pgindent snprintf.c to make it consistent so please
us CVS
Nicolai Tufar wrote:
On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
I have applied a modified version of your patch, attached.
I am so sorry, I sent untested patch again. Thank you very
much for patience in fixing it. The patch looks perfectly
I have applied a modified version of your patch, attached.
initdb will not work without %*s support, so I had to add that. Please
look over my work. I don't think i handle %*1$ but I am not even sure
what that means or if our translators would ever use such a thing. You
can probably test that
Resubmission of yesterday's patch so that it would
cont conflict with Bruce's cvs commit. Pleas apply.
Best regards,
Nicolai.
On Sat, 12 Mar 2005 01:58:15 +0200, Nicolai Tufar [EMAIL PROTECTED] wrote:
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
The
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
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
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
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
Am Mittwoch, 2. März 2005 16:50 schrieb Bruce Momjian:
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
Peter Eisentraut wrote:
Am Mittwoch, 2. M?rz 2005 16:50 schrieb Bruce Momjian:
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
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Does it help if you flip the order of the snprintf and vsnprintf
functions in snprintf.c?
Yes, it fixes the problem and I have applied the reordering
Tom lane wrote:
With CVS-tip snprintf I get
result = '3 42'
result = '3 3505'
I get similar results:
result = '3 42'
result = '9e-313 1413754129'
Now I agree with you, it is fundamentally broken.
We need to replace this implementation.
Bruce Momjian wrote:
I can confirm that using %I64d for
Nicolai Tufar [EMAIL PROTECTED] writes:
I started with FreeBSD's vsnprintf() at first
but was set back by it's complexity and decided to
modify the port/snprintf.c code. Now would you like me
to incorporate FreeBSD's one into the code.
Give me a week and I will come with the patch.
It's all
13 matches
Mail list logo
