5 ms·

I'm not convinced people should be writing applications in C if they can't call memcpy safely. (I say this not to downplay the many pitfalls of writing correct

I'm not convinced people should be writing applications in C if they can't call memcpy safely. (I say this not to downplay the many pitfalls of writing correct C, but to suggest that anyone giving less than careful consideration of the arguments to memcpy each time it is used is better off not using C at all -- we have many fine alternatives.)

kennywinker 13y ago
Short of implementing some kind of drivers license for C coders, I think this is a bad way to look at things. There will always be programs written by people who don't know about buffer overruns, or SQL injection, or just aren't thinking about security at the time because it's a trivial piece of code that "won't make it into a production environment". You can tell them they shouldn't be doing what they are doing all you want, but that doesn't fix the security problem. Fix the tools, don't blame people for using them as best they know how.
- tokenrove 13y ago
  I think there are limits. How do you "fix" assembly language without simultaneously breaking it? The best way to fix C is to use OCaml or Rust or something instead.
  - EpicEng 13y ago
    Yeah... if only I could get an OCaml compiler for my micro...
dkersten 13y ago
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.

kennywinker 13y ago

Short of implementing some kind of drivers license for C coders, I think this is a bad way to look at things. There will always be programs written by people who don't know about buffer overruns, or SQL injection, or just aren't thinking about security at the time because it's a trivial piece of code that "won't make it into a production environment". You can tell them they shouldn't be doing what they are doing all you want, but that doesn't fix the security problem. Fix the tools, don't blame people for using them as best they know how.

tokenrove 13y ago
I think there are limits. How do you "fix" assembly language without simultaneously breaking it? The best way to fix C is to use OCaml or Rust or something instead.
- EpicEng 13y ago
  Yeah... if only I could get an OCaml compiler for my micro...

dkersten 13y ago

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.