3 ms·

I don't disagree, but the fact of the matter is that people do - and even people who know how to use these things safely have been known to make mistakes. Flaws

I don't disagree, but the fact of the matter is that people do - and even people who know how to use these things safely have been known to make mistakes. Flaws are found in all kinds of software and there is a LOT of C code out there where these functions were and are the cause of serious security flaws. So sure, you can say that people shouldn't write in C if they can't call memcpy safely, but the truth is that people do and mistakes do get made. It takes a lot of effort and care to make sure that memcpy is never used to copy data that isn't too large for the destination buffer and there are alternatives like mempcpy and memccpy.

comex 13y ago
Perhaps, and in some cases memcpy_s can definitely provide peace of mind, but in a large number of invocations of memcpy (most?), the buffer size is either constant or always equal to the source size (because the buffer was just allocated with that size), and it would feel nannying to me to be required to write the same size twice. Empirically, in my experience, a much higher risk is an integer overflow in the allocation in question. Rather than memcpy_s, I'd prefer a malloc_s that takes a count and element size - like calloc, but without zeroing the buffer, so it doesn't feel like a performance waste to use when that isn't required.
- panzi 13y ago
  Hmm, so a function similar to fread, but reading from another buffer instead of a file.
  - clarry 13y ago
    You can actually use fread on a buffer after opening it with fmemopen(). (POSIX). I'd rather just do the overflow checking before arithmetic.