> If the output was truncated due to this limit, then the return value is the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available.

The initial call with size 0 tells you the necessary length of the buffer for the string you want, but does not include the null byte.

▲

orbisvicis 5 days ago | parent [-]

For clarity, all snprintf calls "return the number of bytes that would be written to s had n been sufficiently large excluding the terminating null byte" [1].

1. https://man7.org/linux/man-pages/man3/fprintf.3p.html

▲

BobbyTables2 5 days ago | parent [-]

I’d argue this is one of the cursed design choices of the standard library.

Way to easy to use the returned value as the “actual length” of the written string. Sure, that was never the intent, but still…

The standard library also makes appending a formatted string to an existing one surprisingly nontrivial…

What should be a 1-liner is about 5-10 lines of code (to include error handling) and is somewhat hard to read. The “cognitive load” for basic operations shouldn’t be high…

	▲	strawhatguy 4 days ago \| parent \| next [-]
		That reminds me of an article where the author was like the most disastrous design choices in all of programming, was the NULL-terminated string. It's telling that no other language since C really does that. I think this was it: https://queue.acm.org/detail.cfm?id=2010365
	▲	Naru41 5 days ago \| parent \| prev [-]
		True. The number can be determined at comp-time. Buffer sizes should be computing manually.