Re: [pgsql-hackers-win32] [HACKERS] snprintf causes regression tests

Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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 with a
> > > > comment.
> > >
> > > Fascinating.
> > >
> > > > I will start working on fixing the large fmtpar allocations now.
> > >
> > > Quite honestly, this code is not worth micro-optimizing because it
> > > is fundamentally broken. See my other comments in this thread.
> >
> > I am working on something that just counts the '%' characters in the
> > format string and allocates an array that size.
> >
> > > Can we find a BSD-license implementation that follows the spec?
> >
> > I would think NetBSD would be our best bet. I will download it and take
> > a look.
>
> Oops, I remember now that NetBSD doesn't support it. I think FreeBSD does.

OK, I have the structure exceess patched at least with this applied
patch.

Have we considered what is going to happen to applications when they use
our snprintf instead of the one from the operating system? I don't
think it is going to always match and might cause confusion. Look at
the confusion is caused us.

Can we force only gettext() to call our special snprintf verions but
leave the application symbol space unchanged?

I just looked at my BSD/OS libpq based on CVS and see [v]snprintf
exported:

$ nm /pg/interfaces/libpq/libpq.so|grep snprintf
00052434 T snprintf
000523e0 T vsnprintf

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073