[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] fixes for apr_vformatter and apr_snprintf

From: Nuutti Kotivuori <naked_at_iki.fi>
Date: 2002-07-11 17:18:06 CEST

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 be just a
>> minor checkup to see if the return value included the nul-byte or
>> not.
>> So, if I want the length, without including the nul-byte - I need
>> to compare the return value against the buffer length I passed in,
>> and substract one if they are equal? I'd like to _depend_ on
>> something working this way, if I do it this way.
> Hmmm... In the current code, if they are equal then it means either
> it fully fit the buffer or was truncated. So yes. Recall that
> ap(r)_snprintf() copies at most size-1, so the length of the
> returned string can only be a maximum of size-1.
> I agree it looks like we're compromising vformatter for a bug in
> apr_psprintf...

OK, so if I make a fix to apr_psprintf to fix it, we can remove the
kludge in vformatter?

After that apr_snprintf returns len-1 if the data just fit and len if
it got truncated. Is this what is wanted?

If so, then the canonical code for getting the amount of chars written
would be:


int chars = apr_snprintf(buffer, SNPRINTF_MAXLEN, format, ...);

I'll try and code the fix for this once I get a confirmation on this.

-- Naked

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 11 17:18:55 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.