Slashdot Mirror
Microsoft To Banish Memcpy()
kyriacos notes that Microsoft will be adding memcpy() to its list of function calls banned under its secure development lifecycle. This reader asks, "I was wondering how advanced C/C++ programmers view this move. Do you find this having a negative impact on the flexibility of the language, and do you think it will restrict the creativity of the programmer?"
As a competent developer, I get extremely annoyed by this sort of shit.
Removing/banning memcpy doesn't change a damn thing cause the first thing I do with things that have to compile in VisualStudio now is add the following defines which turn this shit off:
_CRT_SECURE_NO_WARNINGS
_CRT_NONSTDC_NO_DEPRECATE
If the remove that option I'll simply add memcpy to my standard MS compatibility library that deals with all the other bullshit MS decides to do.
You can't fix stupid. Stop trying. People fuck up VB and C# apps just as much as the fuck up C and C++ apps. So they don't do it with a buffer overflow, they do it by shear stupidity. You'll be more secure by taking away languages that allow non-programmers to pretend to be programmers than making it harder on those of us that are just going to work around what you do anyway.
You're not going to fix broken shitty apps with exploits by removing functions, the functions aren't the problem they do exactly as they are told (or atleast they are supposed to :). You need to fix the programmers who can't clarify what they want done.
http://www.xkcd.com/568/
Second pane:
You'll never find a programming language that frees you from the burden of clarifying your ideas.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
If you haven't tried Ada yet, I highly suggest looking into it. It keeps track of data sizes, types, etc... for the programmer but it will also let you get close to the hardware like C does. It's often used for safety critical software such as that used in aviation.
Unfortunately I can't recommend using Ada to develop windows apps. It's technically possible but you end up importing C library functions to do it. And if you're going to do that, you might as well just use a native development environment that is better suited to the task.
Now, all that's going to happen is that programmers are going to write their own memcpy-like routines using a quicky for-loop or something. It'll be just as bug prone, and harder to detect via automated source code analysis.
Not to mention it'll be slower. memcpy is one of the most optimized functions in any C library. It's frequently handled as a compiler intrinsic, that can do stuff like unroll short copies, generate optimal machine code, etc.
If you're a competent programmer then nothing is unsafe, but obviously there are a lot of stupid programmers out there who make fundamental mistakes fucking with memory when they don't understand what they're doing. What Microsoft is trying to do here is to eliminate a low hanging fruit of software security that has led to hundreds if not thousands of buffer overflow conditions and associated vulnerabilities/exploits.
The trouble is, it doesn't. Banning functions like strcpy made sense, because they were nearly always unsafe to use. On the other hand, if you're memcpying too much data for the destination, there's probably something more fundamentally wrong with your code. This, at best, conceals the bug by truncating the copy - leading to unpredictable issues later in execution instead.
There have been several suggestions to replace memcpy with memcpy_s as the safer alternative. That's fine, I guess, if memcpy_s is part of the ANSI/ISO standard for C, which as far as I know, it is not; just like all the *_s functions.
Microsoft says your code is safer when using the *_s, but it will no longer be portable, it'll be Microsoft-only. They put in a warning in the compiler from VS2005 onwards about using "unsafe" functions, and that you should use *_s, which is a pain because you have to disable it as the project level, there doesn't seem to be anywhere that I've found that can just turn it off permanently. Even using the STL that comes with VS2008 will generate these warnings, even if you never do any explicit memory stuff yourself.
Microsoft did the same thing with the _* functions; a lot of them are just wrappers around their ANSI-compliant versions (_sprintf -> sprintf), but are also not portable; I worked with a guy who wrote/tested all his C code in VS6 then gave it to me to port to Unix and VMS, and the compilers would choke on not having these particular functions.
Microsoft is trying to get lock-in at the language level instead of providing a good set of Win32 API-based functions that make using memcpy() unnecessary.
Actually, memcpy in and of itself is slow. Hand writing your own asm version of memcpy using extended cpu functions is a lot faster as memcpy itself is usually kept basic enough to work on any cpu, including the older cpu's without MMX, SSE, etc.
glibc contains specific implementations for sparc32, powerpc32, powerpc64, i386, i586, cris, i860, rs6000, and m68k. I don't know where you got your idea.
Dewey, what part of this looks like authorities should be involved?
>Or, better yet, if security really was the goal, develop a C-like language that was secure by design?
Or, better yet, if security really was the goal, use Ada.
There, fixed that for you :o)
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
So why is strncpy in the banned function list?
Because strncpy() is as bad as strcpy(). The problem lies in the fact that if the source string is longer than the destination len, then strncpy simply stops the copy without writing a NULL. The next str* function used on the string is likely to crash.