From dev-return-7100-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Thu Jul 11 15:18:27 2002 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 11790 invoked by uid 500); 11 Jul 2002 15:18:27 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 11777 invoked from network); 11 Jul 2002 15:18:26 -0000 To: Jim Jagielski Cc: dev@subversion.tigris.org, dev@apr.apache.org Subject: Re: [PATCH] fixes for apr_vformatter and apr_snprintf References: <200207110124.VAA03988@devsys.jaguNET.com> <87vg7mohsd.fsf@iki.fi> From: Nuutti Kotivuori Date: Thu, 11 Jul 2002 18:18:06 +0300 In-Reply-To: (Jim Jagielski's message of "Thu, 11 Jul 2002 09:10:35 -0400") Message-ID: <87r8ianvip.fsf@iki.fi> Lines: 40 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Nuutti Kotivuori X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: #define SNPRINTF_MAXLEN int chars = apr_snprintf(buffer, SNPRINTF_MAXLEN, format, ...); if(chars >= SNPRINTF_MAXLEN) chars = SNPRINTF_MAXLEN-1; I'll try and code the fix for this once I get a confirmation on this. -- Naked