>
> The big question is why our own vsnprintf() is not being called from
> snprintf() in our port file.
>

I have seen this "problem" before, well, it isn't really a problem I guess.

I'm not sure of the gcc compiler options, but....

On the Microsoft compiler if you specify the option "/Gy" it separates the
functions within the object file, that way you don't load all the
functions from the object if they are not needed.

If, however, you create a function with the same name as another function,
and one is declared in an object compiled with the "/Gy" option, and the
other's object file is not, then if you also use a different function or
reference variable in the object file compiled without the "/Gy" option,
then the conflicting function will probably be used. Make sense?

I would suggest using macro to redefine snprintf and vnsprintf to avoid
the issue:

#define snprintf pg_snprintf
#define vnsprintf pg_vnsprintf

In response to

• Re: snprintf causes regression tests to fail at 2005-03-02 01:55:11 from Bruce Momjian

pgsql-hackers by date

Next:	From: Bruce Momjian	Date: 2005-03-02 13:31:11
	Subject: Re: [HACKERS] UTF8 or Unicode
Previous:	From: Bernd Helmle	Date: 2005-03-02 11:47:02
	Subject: Re: [HACKERS] Development Plans

pgsql-patches by date

Next:	From: Bruce Momjian	Date: 2005-03-02 13:31:11
	Subject: Re: [HACKERS] UTF8 or Unicode
Previous:	From: Magnus Hagander	Date: 2005-03-02 10:30:38
	Subject: Re: [pgsql-hackers-win32] [HACKERS] snprintf causes regression tests to fail

pgsql-hackers-win32 by date

Next:	From: Bruce Momjian	Date: 2005-03-02 15:41:00
	Subject: Re: [pgsql-hackers-win32] snprintf causes regression tests
Previous:	From: Nicolai Tufar	Date: 2005-03-02 09:13:19
	Subject: Re: [pgsql-hackers-win32] snprintf causes regression tests to fail