On Windows, if the native vsnprintf() fills the buffer, it does not add
the terminating NUL. The earlier commit f32edf6b tried to fix the
emulation, but the fix worked only if the formatted string fitted into
the buffer exactly. However, there are callers that do not try to resize
the buffer if it overflows, and in these cases the resulting string
remained without the trailing NUL. This patch adds the NUL in all cases.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
On Windows, if the resulting string fits exactly in the provided buffer,
but not the terminating NUL, then the return value of the system's
vsnprintf is the number of characters written. But since we had reserved
an extra byte anyway, we only need to make sure that the result is
NUL terminated.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
But we still have to cater for the strangeness that on Windows the size
parameter is the number of characters to write, not the size of the buffer.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Some systems (namely HPUX and Windows) return -1 when maxsize in snprintf()
and in vsnprintf() is reached. So replace snprintf() and vsnprintf()
functions with our own ones that return correct value upon overflow.
[jc: verified that review comments by J6t have been incorporated, and
tightened the check to verify the resulting buffer contents, suggested
by Wayne Davison]
Signed-off-by: Michal Rokos <michal.rokos@nextsoft.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
