Looks like PR9932 explains why we have the current behavior... Not sure
if the change from (sp = bep) - (sp bep) makes sense in this case.
We most likely need to flush when we are *at* bep, but I'm not really
sure.
--
===
Jim Jagielski wrote:
Nuutti Kotivuori wrote:
Jim Jagielski wrote:
So if truncated, what is returned *must* be = the length passed
in.
apr_snprintf is not snprintf.
Agreed, but we want some of the same characteristics. Returning
length upon truncation is one of them.
* In no event
At 10:17 AM +0300 7/11/02, Nuutti Kotivuori wrote:
But back to the subject at hand.
I'm a bit uncertain _how_ am I supposed to be using apr_snprintf so
code doesn't break the next time it's behaviour changes? I'm a bit on
a foul mood here, sorry, but this was supposed to be just a minor
checkup
Jim Jagielski wrote:
At 10:17 AM +0300 7/11/02, Nuutti Kotivuori wrote:
But back to the subject at hand.
I'm a bit uncertain _how_ am I supposed to be using apr_snprintf so
code doesn't break the next time it's behaviour changes? I'm a bit
on a foul mood here, sorry, but this was supposed to
Jim Jagielski wrote:
After that apr_snprintf returns len-1 if the data just fit and len
if it got truncated. Is this what is wanted?
It would appear so... Certainly not being able to tell truncation
from it just fit is non-ideal.
Well yes. But now that we have really decided on the
I went through apr_snprintf trying to find whether the value returne
was including or not including a null-terminator. On the way, I
stumbled upon some nastyness. This is what you get when you don't just
write a test program and see how it behaves.
There are a few fixes I made, outlined below.
*
Nuutti Kotivuori wrote:
* apr_snprintf behaved incorrectly when the output was truncated. It
returned the length that was passed in, but that is including the
null-terminator.
From the man page for snprintf():
if the return value is greater than or
equal to the size argument, the
