Re: snprintf heads-up

Question is, what do we do about it. In my opinion, the most 'sensible behavior' would be snprintf() returning the actual amount of characters written. As it doesn't always appear to be the case, the best approach IMHO would be using the bundled snprintf() always, regardless of whether snprintf() is available on the platform. As far as I can tell from glancing through snprintf.c, this version of snprintf() would return the number of characters that were effectively written under all circumstances (I could be wrong, we need to test it). Zeev On Fri, 8 Sep 2000, Stanislav Malyshev wrote: > In a number of places in PHP code, the following construct is used: > > char buffer[LEN]; > ... > buf_len = snprintf(buffer, sizeof(buffer)-1, ....); > > <code basing on buf_len, like memcpy(s,buffer,buf_len)> > > Now, the newest Linux manual I have states about snprintf: > > RETURN VALUE > If the output was truncated, the return value is -1, oth- > erwise it is the number of characters stored, not includ- > ing the terminating null. (Thus until glibc 2.0.6. Since > glibc 2.1 these functions return the number of characters > (excluding the trailing null) which would have been writ- > ten to the final string if enough space had been avail- > able.) > > That means, output of snprintf *can not* be trusted. You should check it > for being inside the array. I don't know yet how the other systems' > snprintfs behave, but at least Linux one cannot be trusted to return > usable value. > > -- Zeev Suraski <zeev@zend.com> http://www.zend.com/