Basically, it encourages you to store only the string pointer and re-calculate the length (or let a library function do so) or use the wrong length value, which means if there's some specific length or capacity worth paying attention to, it's easy to get it wrong.

Really you want both a length, of the data actually in the string, and a capacity, marking how much memory is valid.

If I'm understanding the vulnerability right: strncmp takes three arguments, the beginning of the first string, the beginning of the second string, and the maximum number of bytes to compare. That maximum isn't quite a length or a capacity. It's a bound on the length, if one of the strings isn't null-terminated. But if you provide too small a maximum, it'll only compare the first few characters, and return a value based on that.

In particular they compared the target string to the user-provided string, with a user-provided length, so if you provide an empty string, it compares 0 bytes and returns success.

An API of the form strcmp(struct actual_string a, struct actual_string b) wouldn't have this problem - the actual string structures (instead of a char pointer) would provide a length for both strings, so the API wouldn't let you make this sort of error.

Because occasionally you use wrong length with wrong pointer and read or overwrite something you didn't want to.

It's more convenient and safer to have these two variables packed together as a "string object" and have string functions operate on that - then they always know where the string starts and ends in memory.

If you access a memory location beyond the end of the string, you can get all sorts of unexpected behavior. The string's length is something you'll pretty much always need to take into account.

Many libraries and systems (e.g. Win32) just go with null-terminated strings and their functions don't accept a length argument at all - so I wonder if some people never store the length simply because they don't believe they'll ever need it.