Maybe Microsoft thought they were doing OK on bolting on security as an afterthought, and pretending that it was built into their products from day zero. But they've just jumped the shark.
I am ââ¬Åproudââ¬Â to announce that we intend to add memcpy() will to the SDL C and C++ banned API list later this year as we make further revisions to the SDL.
W.T.F.? Yes, sure, list several security updates that have memcpy in common. But I'm sure that's not the only thing they have in common. memcpy already had a length parameter. If one length parameter is insufficient to prevent muppets from screwing up, what makes you think that adding more of the same is going to have any real effect.
Only Zaphod Beeblebrox would seriously argue that two heads are better than one. If someone is incapable of programming C safely with memcpy, they are still going to be incapable of programming C safely with memcpy_s. How long before we've reached memcpy_s_s_s?
Oh, I thought, so where is memmove_s? They're not announcing that one. it seems that it already exists. And what do we have...
errno_t memmove_s( void *dest, size_t numberOfElements, const void *src, size_t count );
- dest
- Destination object.
- numberOfElements
- Size of the destination buffer.
- src
- Source object.
- count
- Number of bytes of characters to copy.
OK, so I call it like this, right?
void total_balls_up(int *source) {
int dest[4];
if(!memmove_s(dest, 4, source, 2))
return 0;
...
After all, you did describe it as number of elements, and I passed you in number of elements. How long before we have a CVE due to this one?
I guess we now know why Microsoft pulled the plug on the campus bar. It's because the microserfs are already continuously out of their brains on Pan Galactic Gargle Blasters.
void *
SafeMemCpy(void *dst, int dst_len, void *src, int src_len, char *memcpy_password, int memcpy_password_len, int int_size, int ptr_size, __boolean__ yes_please_really_do_it)