Duplicate:
According to "Please Join me in welcoming memcpy() to the SDL Rogues Gallery" memcpy
is being banned as unsafe. It makes sense that gets()
, strcpy
and similar apis where the destination size is unclear. Is memmove()
next?
According to "Please Join me in welcoming memcpy() to the SDL Rogues Gallery" memcpy
is being banned as unsafe. It makes sense that gets()
, strcpy
and similar apis where the destination size is unclear. Is memmove()
next?
The point with all these “safe” methods is:
Of course, you can easily make a call to
memcpy_s()
insecure by getting the buffer sizes wrong.
[Source]
Which is why I find this SDL feature highly over-hyped. Of course, such problems are inherent in a language like C if no precautions are taken by the compiler (or an appropriate runtime, which would be costly in terms of performance and/or memory).
It also makes programs less portable which I personally find is a huge disadvantage. Of course, Microsoft wouldn't necessarily agree.
Migrating the code to C++ with proper use of (checked) iterators might make more sense, where possible. These operations, while also inherently unsafe, are more easily used right, and make wrong code stand out. Of course, caveat emptor, and all those C fans and C++ deniers will be after my skin now …
memmcopy might create an opening for stack overflow by a malicious user. For example: The specific flaw exists during the processing of a malicious WordDocument file. The overflow can be triggered during the parsing at offset 0xb4c in the WordDocument stream. At this offset, there is a WORD size that is used as the third parameter to a memmove call.