On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
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.
Under win32 I am sti
Bruce Momjian writes:
> Is there no way to create a va_arg va_list structure in C?
Exactly. The standard lets you *read out* from such a structure,
but there's no provision for creating one on-the-fly.
regards, tom lane
---(end of broadcast)-
Bruce Momjian writes:
> I am wondering if we should just process long long args and %$ args,
> and pass everything else to the native snprintf.
AFAICS this is a non-starter --- how will you construct the call to
snprintf? Or even vsnprintf? C doesn't provide the tools you need
to make it happen
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
> wrote:
> > > The CVS-tip impleme
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
wrote:
> > The CVS-tip implementation is fundamentally broken and won't work even
> > for our internal uses. I've not wasted time complaining about it
> > because I thought we were going to replace it. If we can't find a
> > usable replacem
On Fri, 11 Mar 2005 01:14:31 -0500, Tom Lane wrote:
> Nicolai Tufar <[EMAIL PROTECTED]> writes:
> > Very well, I too, tend to think that importing some else's solution
> > is the way to go. Tom, have you looked at Trio?
>
> I have not seen it ... but if it looks reasonable to you, have a go
> at i
Nicolai Tufar <[EMAIL PROTECTED]> writes:
> Very well, I too, tend to think that importing some else's solution
> is the way to go. Tom, have you looked at Trio?
I have not seen it ... but if it looks reasonable to you, have a go
at it.
regards, tom lane
-
Tom Lane wrote:
> The CVS-tip implementation is fundamentally broken and won't work even
> for our internal uses. I've not wasted time complaining about it
> because I thought we were going to replace it. If we can't find a
> usable replacement then we're going to have to put a lot of effort
> in
Bruce Momjian writes:
> Please see my posting about using a macro for snprintf. If the current
> implementation of snprintf is enough for our existing translation users
> we probably don't need to add anything more to it because snprintf will
> not be exported to client applications.
The CVS-tip
On Wed, 9 Mar 2005 22:51:27 -0500 (EST), Bruce Momjian
wrote:
> > What do you think about it? Shall I abandon FreeBSD and go ahead
> > Incorporating Trio?
>
> Yes, maybe just add the proper %$ handling from Trio to what we have
> now.
Adding proper %$ from Trio will require too much effort. I wo
Dear all,
After struggling for one week to to integrate FreeBSD's vfprintf.c into
PostgreSQL I finally gave up. It is too dependent on underlying
FreeBSD system functions. To incorporate it into PostgreSQL we need
to move vfprintf.c file itself, two dozen files form gdtoa and a half
a dozen __XXtoa
Bruce Momjian 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 we have to support all the 64-bit speci
On Wed, 2 Mar 2005 09:24:32 +0100, Joerg Hessdoerfer
<[EMAIL PROTECTED]> wrote:
> don't know if PG borrowed the code from here, but according to the manpage
> FreeBSD 5.3 seems to have a quite complete implementation, see
> http://www.freebsd.org/cgi/man.cgi?query=snprintf&apropos=0&sektion=3&manpa
[EMAIL PROTECTED] writes:
> Well, here is a stupid question, do we even know which snprintf we are
> using on Win32? May it be possible that we are using the MingW version
> which may be broken?
The regression tests were not failing until we started using the port/
version ...
On Tue, 1 Mar 2005 15:38:58 -0500 (EST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Is there a reason why we don't use the snprintf that comes with the
> various C compilers?
snprintf() is usually buried in OS libraries. We implement
our own snprintf to make things like this:
snprintf(buf,"%2$
>> I spent all day debugging it. Still have absolutely
>> no idea what could possibly go wrong. Does
>> anyone have a slightest clue what can it be and
>> why it manifests itself only on win32?
>
>It may be that the CLIB has badly broken support for 64bit
>integers on 32
>bit platforms. Does anyo
I spent all day debugging it. Still have absolutely
no idea what could possibly go wrong. Does
anyone have a slightest clue what can it be and
why it manifests itself only on win32?
On Tue, 1 Mar 2005 09:29:07 -0500 (EST), Bruce Momjian
wrote:
> Nicolai Tufar wrote:
> > On Tue, 1 Mar 2005 00:55:
On Tue, 1 Mar 2005 00:55:20 -0500 (EST), Bruce Momjian
> My next guess
> is that Win32 isn't handling va_arg(..., long long int) properly.
>
I am trying various combination of number and types
of parameters in my test program and everything prints fine.
When it comes to pg, it fails :(
> >
18 matches
Mail list logo