Patch rejected. Sorry. Comment is:
The patch of very dubious portability and I'm not even convinced that
it'd provide a net performance improvement.
---
Marko Kreen wrote:
> Attached patch moves decision how much more roo
On 11/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > FWIW, SUS says that vsnprintf should act like snprintf and snprintf:
>
> I dunno where you're reading that, but it's certainly nowhere to be
> found in the version that I read:
>
> http://www.opengroup.
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> FWIW, SUS says that vsnprintf should act like snprintf and snprintf:
I dunno where you're reading that, but it's certainly nowhere to be
found in the version that I read:
http://www.opengroup.org/onlinepubs/007908799/xsh/vfprintf.html
On 11/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > Attached patch moves decision how much more room to allocate
> > from callers of appendStringInfoVA to inside the function,
> > where more info is available.
>
> This is by no stretch of the imagination
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Attached patch moves decision how much more room to allocate
> from callers of appendStringInfoVA to inside the function,
> where more info is available.
This is by no stretch of the imagination "cleaner".
> On systems with broken vsnprintf() it falls b
Attached patch moves decision how much more room to allocate
from callers of appendStringInfoVA to inside the function,
where more info is available.
On systems with broken vsnprintf() it falls back
to doubleing the buffer.
Fixme: the +1 could be something larger? Aligned?
--
marko
cleaner_a
