Re: snprintf()
От | Kate F |
---|---|
Тема | Re: snprintf() |
Дата | |
Msg-id | 20070203042848.GJ390@cats.meow.at обсуждение исходный текст |
Ответ на | Re: snprintf() (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, Feb/ 2/07 11:20:07PM -0500, Tom Lane wrote: > Kate F <kate@cats.meow.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.opgstrcasecmp.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
В списке pgsql-hackers по дате отправления: