Originally, we had a few itoa calls in the code base. But as this function was nonstandard, we added the inttostr wrapper for non-Windows platform support. The problem is, the Windows (and POSIX?) signature is (value, buffer, radix) instead of the (value, buffer, size) specified in the wrapper. This causes code following the radix style signature to risk buffer overrun (tried to specify radix of 10, but instead claimed the buffer could hold 10 bytes), and conversely radix errors for the opposite case (using sizeof(buffer) as the number base).
Because this wrapper was being used in only a few places, for keeping things neat I decided to replace it altogether with the engine/tier1 V_... format functions. This way, we'll have the same unified string format API across platforms, hopefully with less surprises.
As an aside, the Windows secure CRT does have the _itoa_s, which provides the (value, buffer, size, radix) signature, which would be compatible with the wrapper signature, assuming base 10. But I might be leaning towards using V_sprintf_safe(buffer, "%d", num) and similar instead of maintaining the wrapper.
Originally, we had a few
itoacalls in the code base. But as this function was nonstandard, we added theinttostrwrapper for non-Windows platform support. The problem is, the Windows (and POSIX?) signature is(value, buffer, radix)instead of the(value, buffer, size)specified in the wrapper. This causes code following the radix style signature to risk buffer overrun (tried to specify radix of 10, but instead claimed the buffer could hold 10 bytes), and conversely radix errors for the opposite case (usingsizeof(buffer)as the number base).Because this wrapper was being used in only a few places, for keeping things neat I decided to replace it altogether with the engine/tier1
V_...format functions. This way, we'll have the same unified string format API across platforms, hopefully with less surprises.As an aside, the Windows secure CRT does have the
_itoa_s, which provides the(value, buffer, size, radix)signature, which would be compatible with the wrapper signature, assuming base 10. But I might be leaning towards usingV_sprintf_safe(buffer, "%d", num)and similar instead of maintaining the wrapper.