On Fri, Feb/ 2/07 11:20:07PM -0500, Tom Lane wrote:
> Kate F <[EMAIL PROTECTED]> 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 se
Kate F <[EMAIL PROTECTED]> 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
On Fri, Feb/ 2/07 10:52:28PM -0500, Tom Lane wrote:
> Kate F <[EMAIL PROTECTED]> writes:
> > ... does PostgreSQL replace my system's snprintf() prototype with
> > its own implementation's?
>
> We do on some platforms where configure decides the system version
> is deficient ... I don't recall the
Kate F <[EMAIL PROTECTED]> writes:
> ... does PostgreSQL replace my system's snprintf() prototype with
> its own implementation's?
We do on some platforms where configure decides the system version
is deficient ... I don't recall the exact conditions at the moment.
I wouldn't really have expected
Hello,
I've been implementing a type I needed, and happened to be using
snprintf(), since I have C99 available.
ereport(NOTICE,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("%d", snprintf(NULL, 0, "abc";
For me, this reports "0". I beieve it sh
Andrew Dunstan wrote:
I committed the pg_regress change back in Nov but didn't change
buildfarm to use it. And now I look at it more closely I think it
won't work. We have:
/ # locale
/ NOLOCALE :=
ifdef NO_LOCALE
NOLOCALE += --no-locale
endif
I think instead of the += line w
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Which raises another question: can we force the locale on Windows,
or are we stuck with the locale that the machine is set to? But
maybe that belongs in another thread.
I thought we'd put in some sort
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Which raises another question: can we force the locale on Windows, or
are we stuck with the locale that the machine is set to? But maybe that
belongs in another thread.
I thought we'd put in some sort of "no-locale" switch
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Which raises another question: can we force the locale on Windows, or
> are we stuck with the locale that the machine is set to? But maybe that
> belongs in another thread.
I thought we'd put in some sort of "no-locale" switch specifically for
the bui
Tom Lane wrote:
Please test ...
Well, if you look here you'll see a bunch of Turkish messages, because I
forgot to change the locale back ;-)
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-12-06%2011:57:20
Which raises another question: can we force the locale on Wind
t; Subject: Re: [PATCHES] [HACKERS] snprintf() argument
> reordering not working
>
> We hope to put out a new pginstaller in the next few days
> for testing to make sure this has been resolve before releasing 8.1.1.
http://developer.postgresql.org/~dpage/postgresql-8.1t1.zip
DO NOT use
2005/12/6, Nicolai Tufar <[EMAIL PROTECTED]>:
> >
> > IIRC last time I tried this it didn't work too well ;-( I will have
> > another go. I think it's the best way to go.
>
> Very well, I will try to put up a patch to implement it in a couple of days.
Oh boy, it is already fixed. Sorry folks, my e
2005/12/4, Andrew Dunstan <[EMAIL PROTECTED]>:
> Tom said:
>
> >Would it work to modify c.h so that it #include's libintl.h, then #undefs
> >these macros, then #includes port.h to define 'em the way we want?
> >Some or all of this might need to be #ifdef WIN32, but that seems like
> >a reasonably n
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If we don't do this then we need to link snprintf into libpgtypes just
> like we do for ecpg, but it seems like overkill.
It might be overkill today, but what about tomorrow when someone decides
to internationalize libpgtypes? I made it link in there
Tom Lane wrote:
Not sure why my build didn't show the problem in pgtypeslib, though.
That should have failed with or without libintl macros.
On *nix it probably just thinks it's an external symbol to be resolved
later.
cheers
andrew
---(end of broadcast)
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Also, we need a way to stop this from happening all over the build:
> In file included from ../../../../../../src/include/c.h:820,
> from ../../../../../../src/include/postgres.h:48,
> from utf8_and_sjis.c:14:
> ../../.
I did some research and can report what was happening with *printf and
libintl.
Basically, there are two versions of libintl. Versions before 0.13
(November 2003) use the libc version of *printf to handle printing of
translation strings. Version 0.13 and after provide their own *printf
function
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
OK, eyeball this for the REL8_1_STABLE branch, please. It seems to
work for me. No exports necessary.
er try this instead. I missed a line from configure.in
I cleaned this up slightly and committed it into HEAD
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> OK, eyeball this for the REL8_1_STABLE branch, please. It seems to
>> work for me. No exports necessary.
> er try this instead. I missed a line from configure.in
I cleaned this up slightly and committed it into HEAD and 8.1 branches.
It appears to wo
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> OK, eyeball this for the REL8_1_STABLE branch, please. It seems to work
> for me. No exports necessary.
OK, I see a few cleanups I want to make, but given the knowledge that
this patch does work on Win32, I should be able to get it done tonight.
Thanks
Andrew Dunstan wrote:
Tom Lane wrote:
I'm coming around to thinking that the simple solution is just to
use it unconditionally on Windows.
I agree that that's what we should do, but it should be done the same
way we handle other routines from libpgport. None of those are exported
to
Tom Lane wrote:
I'm coming around to thinking that the simple solution is just to use it
unconditionally on Windows.
I agree that that's what we should do, but it should be done the same
way we handle other routines from libpgport. None of those are exported
to our client-side programs
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>> The problem is that the alias will be picked up by every libpq client.
>>
>> Not at all; libpq clients do not import c.h.
> Well, all the programs that use postgres-fe.h do.
Sure, but a
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What about Plan B? Per Bruce's comment, it should really only be ecpg
>> that needs an extra copy of snprintf.o, and it's not like ecpg doesn't
>> already pull in various port/ files for itself.
> The problem is that the alias will b
IL PROTECTED]>, "[EMAIL PROTECTED]"<[EMAIL
PROTECTED]>, "pgsql-hackers@postgresql.org"
Subject: Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
> I'm not sure I see the objection to stripping these out of the *.def files.
It will be a recipe for disaster
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The bad news: if we aren't compiling with NLS enabled, having those
entries in exports.txt makes the libpq build blow up. So either we need
to use pg_*printf unconditionally on Windows, or we need a little
Makefile + sed magic to
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> With luck I can probably wrap this up today for the 8.1 stable branch -
> it would be nice if the new release actually did NLS right.
BTW, core has already agreed to postpone the releases a couple days
while we make sure we have this problem nailed dow
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The bad news: if we aren't compiling with NLS enabled, having those
> entries in exports.txt makes the libpq build blow up. So either we need
> to use pg_*printf unconditionally on Windows, or we need a little
> Makefile + sed magic to strip those ent
Bruce Momjian wrote:
Was the last patch you sent in ready for application, or are you still
fooling with it?
He is still working on it. It did not handle all *printf functions, as
he mentioned, and he might have other changes.
Yeah.
The good news: the new pg_*printf does the rig
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
> > made yesterday, I see the result above, i.e. what we expect from our own
> > breakage of sprintf (i haven't yet updated the snapshot I took).
>
> Ah. OK,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
> made yesterday, I see the result above, i.e. what we expect from our own
> breakage of sprintf (i haven't yet updated the snapshot I took).
Ah. OK, that makes sense.
> But th
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
What is more, when I set the locale of my machine to Turkish and run the
installer project's 8.1_RC1 which I happen to have installed there, and
set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
LOG: "$s"
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> What is more, when I set the locale of my machine to Turkish and run the
> installer project's 8.1_RC1 which I happen to have installed there, and
> set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
> LOG: "$s" veritaban?n tra
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
However, a very simple test shows that the libintl printf does indeed do
%m$ processing:
...
So the next question is why isn't it working in the build.
Is it possible that the build that was being complained of was using ou
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> However, a very simple test shows that the libintl printf does indeed do
> %m$ processing:
> ...
> So the next question is why isn't it working in the build.
Is it possible that the build that was being complained of was using our
previous, very-broken
I wrote:
Bruce Momjian said:
OK, a few things. First, Tom has fixed snprintf.c so it should
properly process positional parameters now. Would you first test the
libintl version of *printf to see if it can process %$ parameters
(probably by hacking up any language file and testing the prin
Bruce Momjian said:
>
> OK, a few things. First, Tom has fixed snprintf.c so it should
> properly process positional parameters now. Would you first test the
> libintl version of *printf to see if it can process %$ parameters
> (probably by hacking up any language file and testing the printing),
OK, a few things. First, Tom has fixed snprintf.c so it should properly
process positional parameters now. Would you first test the libintl
version of *printf to see if it can process %$ parameters (probably by
hacking up any language file and testing the printing), and then try
your patch below
Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that - wind
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > That got me through the backend compile and through libpq to ecpg, which
> > fell over at the link stage complaining about missing references to
> > pg_sprintf and pg_snprintf ... not sure how to fix that - windows
> > experts, ple
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> That got me through the backend compile and through libpq to ecpg, which
> fell over at the link stage complaining about missing references to
> pg_sprintf and pg_snprintf ... not sure how to fix that - windows
> experts, please advise.
Plan A would
Andrew Dunstan wrote:
Tom said:
Would it work to modify c.h so that it #include's libintl.h, then
#undefs
these macros, then #includes port.h to define 'em the way we want?
Some or all of this might need to be #ifdef WIN32, but that seems like
a reasonably noninvasive solution if it can wo
Bruce Momjian wrote:
OK, here is what happened. In March 2005, we got reports of compile
problems on Win32 using NLS:
http://archives.postgresql.org/pgsql-hackers/2005-03/msg00710.php
(See the quoted text under the posted text as well.) Basically,
libintl.h on Win32 replaces *print
Bruce Momjian writes:
> (See the quoted text under the posted text as well.) Basically,
> libintl.h on Win32 replaces *printf calls with its own versions, and
> does it using macros, _just_ like we do. This of course causes
> conflicts and the system fails to compile. The _fix_ was to disable
>
Nicolai Tufar wrote:
> Greetings,
>
> I thought it will be as simple as changing Makefile, the issue seem to be
> much more complicated. Unfortunately I have no PostgreSQL building
> environment handy and will not be able to look at it until the end of next
> week because I am moving my house :( B
Greetings,
Last April we have made some changes to src/ports/snprintf.c so that it
would support argument reordering like %2$s, %1$d and such on
platforms where original snprintf() does not support it, like Windows,
HP-UX or NetBSD.
NLS messages of some languages, like Turkish, rely heavily on ar
Andrew Dunstan wrote:
>
> After some further digging, I think we have 3 problems.
>
> 1. On Windows gettext wants to hijack printf and friends, as below. This
> strikes me as rather unfriendly behaviour by a library header file.
> Anyway, mercifully libintl.h is included in our source in exactly
After some further digging, I think we have 3 problems.
1. On Windows gettext wants to hijack printf and friends, as below. This
strikes me as rather unfriendly behaviour by a library header file.
Anyway, mercifully libintl.h is included in our source in exactly one
spot, so I think the thing to
Bruce Momjian writes:
> so the effect is:
>
> #define pg_snprintf libintl_snprintf
That's not how CPP works.
> In fact, in this example, the system complains about a missing X3 symbol:
>
> #define X1 X2
> #define X2 X3
In this case any occurrence of X1 replaced by X2 but th
Thanks to Andrew Dunstan, I found the cause of these link errors.
Andrew found this in libintl:
#undef snprintf
#define snprintf libintl_snprintf
extern int snprintf (char *, size_t, const char *, ...);
What is happening is that we do:
#define snprintf
Nicolai Tufar wrote:
> On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
> wrote:
> >
> > I have applied a modified version of your patch, attached.
>
> I am so sorry, I sent untested patch again. Thank you very
> much for patience in fixing it. The patch looks perfectly
> fine and works
Nicolai Tufar wrote:
> On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
> wrote:
> >
> > I have applied a modified version of your patch, attached.
>
Here is a patch that fixes the %*$ case.
FYI, I am going to pgindent snprintf.c to make it consistent so please
us CVS for your next patc
On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
wrote:
>
> I have applied a modified version of your patch, attached.
I am so sorry, I sent untested patch again. Thank you very
much for patience in fixing it. The patch looks perfectly
fine and works under Solaris.
Under win32 I am sti
I have applied a modified version of your patch, attached.
initdb will not work without %*s support, so I had to add that. Please
look over my work. I don't think i handle %*1$ but I am not even sure
what that means or if our translators would ever use such a thing. You
can probably test that
Bruce Momjian writes:
> Is there no way to create a va_arg va_list structure in C?
Exactly. The standard lets you *read out* from such a structure,
but there's no provision for creating one on-the-fly.
regards, tom lane
---(end of broadcast)-
Tom Lane wrote:
> Bruce Momjian writes:
> > I am wondering if we should just process long long args and %$ args,
> > and pass everything else to the native snprintf.
>
> AFAICS this is a non-starter --- how will you construct the call to
> snprintf? Or even vsnprintf? C doesn't provide the tool
Bruce Momjian writes:
> I am wondering if we should just process long long args and %$ args,
> and pass everything else to the native snprintf.
AFAICS this is a non-starter --- how will you construct the call to
snprintf? Or even vsnprintf? C doesn't provide the tools you need
to make it happen
Nicolai Tufar wrote:
> On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
> wrote:
> > > The CVS-tip implementation is fundamentally broken and won't work even
> > > for our internal uses. I've not wasted time complaining about it
> > > because I thought we were going to replace it. If we c
Resubmission of yesterday's patch so that it would
cont conflict with Bruce's cvs commit. Pleas apply.
Best regards,
Nicolai.
On Sat, 12 Mar 2005 01:58:15 +0200, Nicolai Tufar <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
> wrote:
> > > The CVS-tip impleme
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
wrote:
> > The CVS-tip implementation is fundamentally broken and won't work even
> > for our internal uses. I've not wasted time complaining about it
> > because I thought we were going to replace it. If we can't find a
> > usable replacem
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > >> I'm not sure that macros can have variable number of arguments on all
> > >> supported platforms. I've been burnt by this before.
> >
> > > The actual patch is:
> >
> > > + #ifdef __GNUC__
> > > + #define vsnprintf(.
Tom Lane wrote:
> Bruce Momjian writes:
> >> I'm not sure that macros can have variable number of arguments on all
> >> supported platforms. I've been burnt by this before.
>
> > The actual patch is:
>
> > + #ifdef __GNUC__
> > + #define vsnprintf(...)pg_vsnprintf(__VA_ARGS
Bruce Momjian writes:
>> I'm not sure that macros can have variable number of arguments on all
>> supported platforms. I've been burnt by this before.
> The actual patch is:
> + #ifdef __GNUC__
> + #define vsnprintf(...)pg_vsnprintf(__VA_ARGS__)
> + #define snpr
[EMAIL PROTECTED] wrote:
> > Tom Lane wrote:
> >> [EMAIL PROTECTED] writes:
> >> >>> Please see my posting about using a macro for snprintf.
> >>
> >> > Wasn't the issue about odd behavior of the Win32 linker choosing the
> >> wrong
> >> > vnsprintf?
> >>
> >> You're right, the point about the macr
> Tom Lane wrote:
>> [EMAIL PROTECTED] writes:
>> >>> Please see my posting about using a macro for snprintf.
>>
>> > Wasn't the issue about odd behavior of the Win32 linker choosing the
>> wrong
>> > vnsprintf?
>>
>> You're right, the point about the macro was to avoid linker weirdness on
>> Windo
Nicolai Tufar wrote:
> On Thu, 10 Mar 2005 16:26:47 -0500 (EST), Bruce Momjian
> wrote:
> > Please see my posting about using a macro for snprintf. If the current
> > implementation of snprintf is enough for our existing translation users
> > we probably don't need to add anything more to it beca
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> >>> Please see my posting about using a macro for snprintf.
>
> > Wasn't the issue about odd behavior of the Win32 linker choosing the wrong
> > vnsprintf?
>
> You're right, the point about the macro was to avoid linker weirdness on
> Windows. We nee
On Fri, 11 Mar 2005 01:14:31 -0500, Tom Lane wrote:
> Nicolai Tufar <[EMAIL PROTECTED]> writes:
> > Very well, I too, tend to think that importing some else's solution
> > is the way to go. Tom, have you looked at Trio?
>
> I have not seen it ... but if it looks reasonable to you, have a go
> at i
Nicolai Tufar <[EMAIL PROTECTED]> writes:
> Very well, I too, tend to think that importing some else's solution
> is the way to go. Tom, have you looked at Trio?
I have not seen it ... but if it looks reasonable to you, have a go
at it.
regards, tom lane
-
Tom Lane wrote:
> The CVS-tip implementation is fundamentally broken and won't work even
> for our internal uses. I've not wasted time complaining about it
> because I thought we were going to replace it. If we can't find a
> usable replacement then we're going to have to put a lot of effort
> in
[EMAIL PROTECTED] wrote:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >> > Please see my posting about using a macro for snprintf. If the
> >> current
> >> > implementation of snprintf is enough for our existing translation
> >> users
> >> > we probably don't need to add anything more to it b
[EMAIL PROTECTED] writes:
>>> Please see my posting about using a macro for snprintf.
> Wasn't the issue about odd behavior of the Win32 linker choosing the wrong
> vnsprintf?
You're right, the point about the macro was to avoid linker weirdness on
Windows. We need to do that part in any case.
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > Please see my posting about using a macro for snprintf. If the
>> current
>> > implementation of snprintf is enough for our existing translation
>> users
>> > we probably don't need to add anything more to it because snprintf
>> will
>> > not be exp
Tom Lane wrote:
> Bruce Momjian writes:
> > Please see my posting about using a macro for snprintf. If the current
> > implementation of snprintf is enough for our existing translation users
> > we probably don't need to add anything more to it because snprintf will
> > not be exported to client
Bruce Momjian writes:
> Please see my posting about using a macro for snprintf. If the current
> implementation of snprintf is enough for our existing translation users
> we probably don't need to add anything more to it because snprintf will
> not be exported to client applications.
The CVS-tip
On Thu, 10 Mar 2005 16:26:47 -0500 (EST), Bruce Momjian
wrote:
> Please see my posting about using a macro for snprintf. If the current
> implementation of snprintf is enough for our existing translation users
> we probably don't need to add anything more to it because snprintf will
> not be expo
Nicolai Tufar wrote:
> On Wed, 9 Mar 2005 22:51:27 -0500 (EST), Bruce Momjian
> wrote:
> > > What do you think about it? Shall I abandon FreeBSD and go ahead
> > > Incorporating Trio?
> >
> > Yes, maybe just add the proper %$ handling from Trio to what we have
> > now.
>
> Adding proper %$ from
On Wed, 9 Mar 2005 22:51:27 -0500 (EST), Bruce Momjian
wrote:
> > What do you think about it? Shall I abandon FreeBSD and go ahead
> > Incorporating Trio?
>
> Yes, maybe just add the proper %$ handling from Trio to what we have
> now.
Adding proper %$ from Trio will require too much effort. I wo
Nicolai Tufar wrote:
> Dear all,
> After struggling for one week to to integrate FreeBSD's vfprintf.c into
> PostgreSQL I finally gave up. It is too dependent on underlying
> FreeBSD system functions. To incorporate it into PostgreSQL we need
> to move vfprintf.c file itself, two dozen files form g
>From what I recall from the conversation, I would say rename the vsprintf
and the sprintf functions in postgres to pq_vsnprintf and pq_snprintf.
Define a couple macros: (in some common header, pqprintf.h?)
#define snprintf pq_snprintf
#define vsnprintf pq_snprintf
Then just maintain the postgres
Dear all,
After struggling for one week to to integrate FreeBSD's vfprintf.c into
PostgreSQL I finally gave up. It is too dependent on underlying
FreeBSD system functions. To incorporate it into PostgreSQL we need
to move vfprintf.c file itself, two dozen files form gdtoa and a half
a dozen __XXtoa
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> 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.
>
> > Agreed, and we have t
> Bruce Momjian writes:
>> Tom Lane wrote:
>>> 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.
>
>> Agreed, and we have to support all the 64-b
Bruce Momjian writes:
> Tom Lane wrote:
>> 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.
> Agreed, and we have to support all the 64-bit speci
>
> Yes, strangly the Window's linker is fine because libpqdll.def defines
> what symbols are exported. I don't think Unix has that capability.
A non-static "public" function in a Windows DLL is not available for
dynamic linking unless explicitly declared as dll export. This behavior is
completel
Tom Lane wrote:
> Bruce Momjian writes:
> > Have we considered what is going to happen to applications when they use
> > our snprintf instead of the one from the operating system?
>
> Hmm ...
>
> First line of thought: we surely must not insert a snprintf into
> libpq.so unless it is 100% up to
>
> 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 sep
On Wed, 2 Mar 2005 09:24:32 +0100, Joerg Hessdoerfer
<[EMAIL PROTECTED]> wrote:
> don't know if PG borrowed the code from here, but according to the manpage
> FreeBSD 5.3 seems to have a quite complete implementation, see
> http://www.freebsd.org/cgi/man.cgi?query=snprintf&apropos=0&sektion=3&manpa
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> Does it help if you flip the order of the snprintf and vsnprintf
> > >> functions in snprintf.c?
> >
> > > Yes, it fixes the problem and I have applied the reordering with a
> > > comment.
> >
> > Fasci
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Does it help if you flip the order of the snprintf and vsnprintf
> >> functions in snprintf.c?
>
> > Yes, it fixes the problem and I have applied the reordering with a
> > comment.
>
> Fascinating.
>
> > I will start working on fi
Bruce Momjian writes:
> Tom Lane wrote:
>> Does it help if you flip the order of the snprintf and vsnprintf
>> functions in snprintf.c?
> Yes, it fixes the problem and I have applied the reordering with a
> comment.
Fascinating.
> I will start working on fixing the large fmtpar allocations now.
Tom Lane wrote:
> Bruce Momjian writes:
> > I think this means it is finding our /port/snprintf(), but when it calls
> > vsnprintf, it must be using some other version, probably the operating
> > system version that doesn't support %lld.
>
> Ya know, I was wondering about that but dismissed it be
Tom Lane wrote:
> Bruce Momjian writes:
> > I think this means it is finding our /port/snprintf(), but when it calls
> > vsnprintf, it must be using some other version, probably the operating
> > system version that doesn't support %lld.
I can confirm that using "%I64d" for the printf format allo
Bruce Momjian writes:
> I think this means it is finding our /port/snprintf(), but when it calls
> vsnprintf, it must be using some other version, probably the operating
> system version that doesn't support %lld.
Ya know, I was wondering about that but dismissed it because the
routines were all
I have some new information. If I add the attached patch to snprintf.c,
I should see see snprintf() being called printing "0", vsnprintf()
printing "1" and dopr(), "2". However, I only see "0" printing in the
server logs.
I think this means it is finding our /port/snprintf(), but when it calls
v
On Tue, 1 Mar 2005 16:20:50 -0500 (EST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> Well, here is a stupid question, do we even know which snprintf we are
> using on Win32? May it be possible that we are using the MingW version
> which may be broken?
Defenitely not. I checked it by placing
[EMAIL PROTECTED] writes:
> Well, here is a stupid question, do we even know which snprintf we are
> using on Win32? May it be possible that we are using the MingW version
> which may be broken?
The regression tests were not failing until we started using the port/
version ...
> On Tue, 1 Mar 2005 15:38:58 -0500 (EST), [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> Is there a reason why we don't use the snprintf that comes with the
>> various C compilers?
>
> snprintf() is usually buried in OS libraries. We implement
> our own snprintf to make things like this:
> snpr
On Tue, 1 Mar 2005 15:38:58 -0500 (EST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Is there a reason why we don't use the snprintf that comes with the
> various C compilers?
snprintf() is usually buried in OS libraries. We implement
our own snprintf to make things like this:
snprintf(buf,"%2$
>> I spent all day debugging it. Still have absolutely
>> no idea what could possibly go wrong. Does
>> anyone have a slightest clue what can it be and
>> why it manifests itself only on win32?
>
>It may be that the CLIB has badly broken support for 64bit
>integers on 32
>bit platforms. Does anyo
1 - 100 of 116 matches
Mail list logo
