René Scharfe <l.s.r@xxxxxx> writes: > strbuf_addf() has been reporting a negative return value of vsnprintf(3) > as a bug since f141bd804d (Handle broken vsnprintf implementations in > strbuf, 2007-11-13). Other functions copied that behavior: > > 7b03c89ebd (add xsnprintf helper function, 2015-09-24) > 5ef264dbdb (strbuf.c: add `strbuf_insertf()` and `strbuf_vinsertf()`, 2019-02-25) > 8d25663d70 (mem-pool: add mem_pool_strfmt(), 2024-02-25) > > However, vsnprintf(3) can legitimately return a negative value if the > formatted output would be longer than INT_MAX. Stop accusing it of > being broken and just report the fact that formatting failed. """ ... function returns the number of characters that would have been written had n been sufficiently large, not counting the terminating null character, or a negative value if an encoding error occurred. Thus, the null-terminated output has been completely written if and only if the returned value is nonnegative and less than n.""" is what I read in some versions of ISO/IEC 9899. It is curious that it does not say anything about the consequence of a parameter error arising from int (the type snprintf family of functions returns) being narrower than size_t (the type of the parameter n), but your point still stands that vsnprintf() can legitimately fail, and it is not a programming error. Thanks, will queue.
