"Ronald S. Bultje" <[email protected]> writes: > Hi, > > On Wed, Aug 1, 2012 at 11:58 AM, Måns Rullgård <[email protected]> wrote: >> Luca Barbato <[email protected]> writes: >> >>> +#if !HAVE_SNPRINTF >>> +#ifdef _MSC_VER >>> +#define vsnprintf _vsnprintf >>> +#endif >>> + >>> +int snprintf(char *buffer, size_t bufsize, const char *fmt, ...) >>> +{ >>> + va_list ap; >>> + int ret; >>> + >>> + if ((int)bufsize <= 0) return -1; >>> + va_start(ap, fmt); >>> + ret = vsnprintf(buffer, bufsize-1, fmt, ap); >>> + if (ret < 0) { >>> + buffer[bufsize - 1] = '\0'; >>> + ret = bufsize - 1; >>> + } >>> + va_end(ap); >>> + return ret; >>> +} >> >> This assumes that any system without snprintf will have vsnprintf with >> microsoft semantics. That's a pretty bold assumption. > > As for vsnprintf behaviour, from MSDN: > "vsnprintf, _vsnprintf, and _vsnwprintf return the number of > characters written if the number of characters to write is less than > or equal to count; if the number of characters to write is greater > than count, these functions return -1 indicating that output has been > truncated. The return value does not include the terminating null, if > one is written." > > So if format, buffer != NULL and count > 0, a return value of -1 means > that the buffer was overrun and is filled with data ("truncated"), so > writing a '\0' at the end and returning count should be OK then.
What if something else goes wrong causing it to return -1? The documentation is a bit sketchy on failure modes. The safest solution is probably to zero-fill the whole buffer before calling the _vsnprintf() with a size one less than the actual buffer size. > As you pointed out, if the return value equals count, no zero was > written and we should add that. > > Do we care that the return value of this snprintf() drop-in will not > be the amount of characters that would have been written, but is > simply count, if the output was truncated? I don't think we currently rely on that behaviour anywhere, but it's always risky to deviate from the standard. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
