Re: [PATCH] don't report vsnprintf(3) error as bug

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2024, 19:26 UTC
Message-ID: <xmqqa5lm1pr5.fsf@gitster.g>
In-Reply-To: <ea752a2b-9b74-4a59-a037-4782abf7161e@web.de>

René Scharfe <l.s.r@web.de> writes:

Show 11 quoted lines

> 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.