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
Me and Sander Striker made a deal. He and I decided to fix
apr_psprintf the same way - including the removal of the older "fix"
in apr_vformatter. So, Sander is going to fix and commit the
apr_psprintf and apr_vformatter things - and I am going to supply the
testcases to make sure apr_vformatter an
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
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. R
Jim Jagielski wrote:
> 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():
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.
*
