On Sun, 11 Jan 2004, Peter Eisentraut wrote:
PE> Denis N. Stepanov wrote:
PE> > snprintf()/vsnprintf() functions are not ANSI-compliant
PE>
PE> Yes, they are.
Sorry, I was talking about ANSI X3.159-1989, which certainly does not declare
snprintf(). In practice it is diffucult to count on, say, C9
Denis N. Stepanov wrote:
> snprintf()/vsnprintf() functions are not ANSI-compliant
Yes, they are.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
On Thu, 8 Jan 2004, Tom Lane wrote:
TL> "PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
TL> > Some OSes lack proper snprintf()/vsnprintf() fuctions so PostgreSQL includes
TL> > its own version (src/port/snprintf.c) during building. Unfortunately, this
TL> > version of snprintf() is not reentran
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What we could do is to throw a compile #error if you hit our own
> snprintf() and are compiling with threads enabled.
Good thought. If we get any complaints then we can reconsider applying
this patch, otherwise there's no need.
Tom Lane wrote:
> "PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> > Some OSes lack proper snprintf()/vsnprintf() fuctions so PostgreSQL includes
> > its own version (src/port/snprintf.c) during building. Unfortunately, this
> > version of snprintf() is not reentrant (it uses global vars to k
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> Some OSes lack proper snprintf()/vsnprintf() fuctions so PostgreSQL includes
> its own version (src/port/snprintf.c) during building. Unfortunately, this
> version of snprintf() is not reentrant (it uses global vars to keep internal
> state),
The following bug has been logged online:
Bug reference: 1044
Logged by: Denis Stepanov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: Any OS lacking proper snprintf()
Description:snprintf() shipped with PostgreSQL is not thread safe
D
