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
