Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: Jim Jagielski <jim@jaguNET.com>
Message-Id: <200207110124.VAA03988@devsys.jaguNET.com>
Subject: Re: [PATCH] fixes for apr_vformatter and apr_snprintf
To: naked@iki.fi (Nuutti Kotivuori)
Date: Wed, 10 Jul 2002 21:24:39 -0400 (EDT)
Cc: jim@jagunet.com, dev@subversion.tigris.org, dev@apr.apache.org
Reply-To: jim@jagunet.com
In-Reply-To: <87znwznryf.fsf@iki.fi> from "Nuutti Kotivuori" at Jul 11,
 2002 01:22:48 AM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Nuutti Kotivuori 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 does apr_snprintf return a negative number.  It's not possible
>  * to distinguish between an output which was truncated, and an output which
>  * exactly filled the buffer.
> 
> If this comment is changed, I can fix try to fix these functions to
> behave as expected again.
> 

Seems to me that this is the way apr_snprintf() has evolved to be. I can't
recall the exact reasons why this happened, but I'm sure that the cvs
logs provide the detail. Certainly, ap_snprintf() (from which apr_snprintf
was derived) did not start this way, but was instead added in to provide
an ANSI snprintf() implementation. But it has since been changed to
not be a drop-in replacement of snprint() with, as you say, documented
differences (ala cpystrn())

-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
      "A society that will trade a little liberty for a little order
             will lose both and deserve neither" - T.Jefferson