4 ms·

My point stands. C/C++ aren’t memory safe. You can’t just copy stuff around in memory and expect the compiler to fix it for you when the sizes don’t match. This

• loeg 8y ago
  C and C++ give you low level tools, in a variety of senses. For backwards-compatibility reasons, which is a big part of the value of languages like C, C++, Go, and Java, removing anything is difficult or impossible. We barely got rid of gets(3) in C11, which is and has always been impossible to use safely. In contrast, it is at least possible to use the non-n versions of string routines safely. In addition, the 'n' versions have deleterious side effects that make their adoption unappealing: * zero padding to n * no nul termination for strings of length n or longer The BSD 'l' versions (strlcpy, etc) don't have either of those first two problems, but do have: * not in standard C, nor POSIX; * as a result, glibc still refuses to implement them In addition, some people will inevitably complain that both 'n' and 'l' variants inevitably truncate source strings if they don't fit, and that therefore no one should use either of them, you should just perfectly calculate lengths and use the unchecked ones without making mistakes. I can't tell if these people are delusional or trolling, but realistically, programmers make mistakes, and using unchecked string routines is a common source of buffer overflow; this is usually a worse problem than string truncation. Your point doesn't stand.