apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: [PATCH] fixes for apr_vformatter and apr_snprintf
Date Thu, 11 Jul 2002 01:24:39 GMT
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

Mime
View raw message