Skip site navigation (1) Skip section navigation (2)

Re: snprintf()

From: Kate F <kate(at)cats(dot)meow(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: snprintf()
Date: 2007-02-03 04:28:48
Message-ID: 20070203042848.GJ390@cats.meow.at (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Feb/ 2/07 11:20:07PM -0500, Tom Lane wrote:
> Kate F <kate(at)cats(dot)meow(dot)at> writes:
> > On Fri, Feb/ 2/07 10:52:28PM -0500, Tom Lane wrote:
> >> I wouldn't really have expected that to happen on any *BSD, but you
> >> could look into the generated Makefile.global to find out.
> 
> > I don't see anything that looks relevant for my Makefile.global; I
> > would be surprised if NetBSD's were overridden too!
> 
> Sorry for not being specific: the thing to check is whether that
> file's definition for LIBOBJS includes snprintf.o.  If it does,
> the code in src/port/snprintf.c would get sucked in.
> 
> If it doesn't, then I confess bafflement as to why snprintf isn't
> acting as you'd expect on your machine.

Just these:

LIBOBJS =  copydir.o dirmod.o exec.o noblock.o path.o pipe.o pgsleep.o
	pgstrcasecmp.o qsort.o qsort_arg.o sprompt.o thread.o

(More than I expected, actually)

I am imagining the compiler (gcc, here) has some flags to explicitly
select if C99 (which is what I tested my stand-alone example with)
or SUS behaviour is to be used. I'm not really sure how I'd set that,
though - I imagine I'd need to recompile the backend with -std=C99?

Regards,

-- 
Kate

In response to

pgsql-hackers by date

Next:From: Michael FuhrDate: 2007-02-03 09:18:05
Subject: \copy (query) delimiter syntax error
Previous:From: Tom LaneDate: 2007-02-03 04:20:07
Subject: Re: snprintf()

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group