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

> 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".

//Magnus

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".

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

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 snprintf()?  Our code itself doesn't need the
> positional parameters.

No, it's exactly our code that needs the snprintf().  libintl does not need
it.

> Could we read the snprintf translation string and process positional
> parameters _before_ we sent it to gettext()?

That would defeat the entire point of this exercise.  Then translators would
have to translate each possible substitution separately and we wouldn't need
positional parameters at all.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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 library
> > for our replacement snprintf()?  Our code itself doesn't need the
> > positional parameters.
>
> No, it's exactly our code that needs the snprintf().  libintl does not need
> it.

OK, I figured that out later.  gettext() gets the string, but we are the
ones to match the string to the args.

> > Could we read the snprintf translation string and process positional
> > parameters _before_ we sent it to gettext()?
>
> That would defeat the entire point of this exercise.  Then translators would
> have to translate each possible substitution separately and we wouldn't need
> positional parameters at all.

Right.

Should we consider using a macro for snprintf/vsnprintf/printf in our
code and map those to pg_* names so we don't let those symbols out of
our code?  The big problem is that client apps like psql need the
port/snprintf functions we have.

We actually have libpgport on the link line for clients so it is really
only libpq exporting it that is a problem.  If we could prevent that we
would be fine.

I think we got away with replacing system functions in the past because
we were replacing either broken or missing functions.  In this case,
snprintf has a variety of format flags, some OS-specific, and the
functionality we are adding is not critical in most applications.

--
  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