The point of the _s
functions is to be paranoid about buffer overflows. All buffers therefore should be associated with a size.
Your proposal to use a two-character string would mean that either the colon would be omitted (which from a usage perspective would be annoying) or would mean that the string is not NUL-terminated, which probably is unexpected (especially since it would be inconsistent with all of the other output parameters, which are NUL-terminated) and which then could lead to other security vulnerabilities.
Even if you amended your proposal to use a fixed-size buffer of three characters instead of two, in C, declaring array parameters to functions doesn't really do anything; the compiler will not enforce that an argument is an array of the correct size. That is, a function like:
void foo(int array[3]);
is not actually any different from:
void foo(int* array);
If _splitpath_s
did not take a driveNumberOfElements
parameter, it would be easier for callers to accidentally pass buffers that are too small. While it's true that callers can still do that in its current form, the presence of the explicit driveNumberOfElements
parameter should make callers pay some attention to this.
Finally, in theory, drives someday might not be restricted to single characters, so a version of _splitpath_s
that takes a driveNumberOfElements
parameter is a bit more future-proof. (In practice, however, such a change would break lots of existing code.)