apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: apr_snprintf not compliant
Date Sat, 24 Aug 2002 01:47:53 GMT
We are already not compliant, since we overload %p.

Not sure if I understand #1: If len is 0, we return 0 and don't check
buff at all. Or do you mean a length of 0 (or 1) should set
*buffer to NULL?

Assuming the later then +1 on both, not so much to be compliant but because
it's the Right Thing :)

rbb@apache.org wrote:
> 
> apr_snprintf and apr_vsnprintf are not compliant with the POSIX snprint
> standard currently.  There are two problems.  1)  a length of 0 should
> allow the buffer to be NULL, and it should return the computed length of
> the requested string.  This doesn't currently happen.  2)  Specifying a
> string precision doesn't work correctly.  The common reason for specifying
> a string precision, is that you don't ahve a NULL-terminated string, but
> we always call strlen on the string that is passed in.  Problem 2 is in
> GNATS as bug 8554, and it has a fix.  Problem 1 is not in any bug DB, but
> I have a fix already.
> 
> My question, is whether we really want to fix these problems, because we
> don't _have_ to be POSIX compliant.  My own opinion is that they should be
> fixed.
> 
> Ryan
> 
> 
> _______________________________________________________________________________
> Ryan Bloom                        	rbb@apache.org
> 550 Jean St
> Oakland CA 94610
> -------------------------------------------------------------------------------
> 


-- 
===========================================================================
   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