On 2024-08-05 16:13, Martin Dorey wrote:
"Beginning with the UCRT in Visual Studio 2015 and Windows 10, snprintf is no longer identical to _snprintf. The snprintf behavior is now C99 standard conformant. The difference is that if you run out of buffer, snprintf null-terminates the end of the buffer and returns the number of characters that would have been required whereas _snprintf doesn't null-terminate the buffer and returns -1. Also, snprintf() includes one more character in the output because it doesn't null-terminate the buffer."
That's fine, and doesn't affect the validity of the patch. The patch (along with the existing code in GNU Make) uses the following calling convention:
If snprintf (buf, sizeof buf, ...) returns an integer I such that (0 <= I < sizeof buf) then the snprintf worked, the contents of buf[0] through buf[I] are valid, and buf[I] == '\0'. Otherwise snprintf didn't work and buf's contents are indeterminate.
As long as callers use this convention, they're OK regardless of whether the implementation conforms to POSIX or to traditional Microsoft APIs.
"... Also, snprintf() includes one more character in the output because it doesn't null-terminate the buffer." (I don't understand that last sentence, though I would if it said _snprintf rather than snprintf.)
Yes it certainly is written poorly. But it doesn't matter what it means, so long as GNU Make's callers stick with the above convention.
