apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: apr/strings apr_strings.c
Date Wed, 30 Jun 2004 13:57:22 GMT
At 08:17 AM 6/30/2004, Jeff Trawick wrote:
>I like Joe's suggestion of catching it in the test suite.  If the API is ever changed
so that the caller specifies the length of their buffer, then there will be an interesting
case which apr_snprintf() could catch.

Unfortunately, you would need to test the full range of possible inputs
or you won't catch an edge case.

One question, perhaps, is why we silently succeed while truncating the
output string in apr_snprintf().  Obviously some snprintf's pass, some fail,
so there must be some religious argument over 'proper' behavior.

My personal philosophy, retval -1 for apr_snprintf() would tell the user we 
succeeded in filling their buffer, and then choked.  They gave us the size
of the buffer, so they should know how much was filled if they are happy
with the truncated result

Because the (new) flavor can never overflow (invoking apr_snprintf), I'd be
happy ignoring the retval entirely.  If the last position is non-alpha, the
user knows something was borked.  Either way, there isn't the risk of
an overflow anymore.


View raw message