Unsafe at any speed: Memcpy() banished in Redmond • The Register
So correct me if I'm wrong here... Microsoft is "banning" this function simply because it's a sharp knife and they deem their coders too irresponsible to be handling it?
Unsafe at any speed: Memcpy() banished in Redmond • The Register
So correct me if I'm wrong here... Microsoft is "banning" this function simply because it's a sharp knife and they deem their coders too irresponsible to be handling it?
I think this probably means that everybody is supposed to use the "secure" versions of these functions.
Yawn. And as it turns out gcc does not support some Microsoft-specific non-standard extension, go figureDevelopers who want to be SDL compliant will instead have to replace memcpy() functions with memcpy_s, a newer command that takes an additional parameter delineating the size of the destination buffer. The command is already supported in Microsoft's Visual C++, but according to Ullrich, native support doesn't yet seem to be available in the GCC compiler.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
The solution? Keep your software easy to port by not using Visual C++ at all. Use a real compiler. This is one of the reasons I rarely have, and hopefully never again will, use Visual C++.
Actually, I only code for linux anyway.
To my knowledge the SDL is not mandatory. So this is pretty much mute to anyone who simply wishes to use the standard functions. The _s functions are a compiler extension that just happens is more visible due to dubiously written warning messages at compile time (messages that you can turn off with a compiler directive).Originally Posted by EVOEx
I hope you aren't suggesting building our MS Windows code with MinGW...
Ah. Ok. That explains it then.
Last edited by Mario F.; 09-09-2009 at 03:39 AM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Yawn, and everyone knows that adding latency to a bottleneck is how you compete in the global economy. I suspect that it's not the programmers in the developed nations that have problems with the 'unsafe' functions, its the 3rd world programmers that work for $5 a day and have a 6th grade education that mess things up.
Programming languages are not like children's playgrounds where everything must either be soft or have round edges and all toys have to be big enough so they couldn't be swallowed.
Programmers now have to cut bread with origami knives?
"The Internet treats censorship as damage and routes around it." - John Gilmore
>Programmers now have to cut bread with origami knives?
Yeah, let's not overreact or anything.
Removing and replacing unsafe functions, to improve security. A step in the right direction.
Humans are the weakest link in security, so why not provide safer tools to reduce/negate the human factor?
It's not like the functionality is completely eliminated - the same thing can be done with marginally different code.
I don't think there is a need to be opposed to these type of compiler extensions. Well, for the very reason they are compiler extensions or optional (and configurable) process templates.
In fast-food software development environments or in large projects where there is a strong need for preemptive measures concerning bug generation, these functions are a welcome addition. To my knowledge, they aren't even hard to port to other systems/compilers. There's really nothing that isn't perfectly transparent about these functions. Personally, I actively support their addition.
Sure, the terms often used around them are somewhat annoying. "Banned" and "Deprecated" ignore the very nature of the programming language and confer to the standard an image of an irresponsible set of rules. This annoys me slightly. But I rather prefer an optional set of tools that allows any programmer (me included) to construct safer applications than to stick to nice but innefective loyalties.
As long as the standard versions remain for those cases I know what I am doing and that I can use more often as my understanding of the language grows, all should be well.
edit: Much, much worse are those cases where the standards are indeed completely ignored. There aren't many complaints though. Maybe because exception specifications isn't on every programmer's menu and and as such all that loyalty goes into the bin of "I don't use it, who cares!". Right.
Last edited by Mario F.; 09-09-2009 at 05:04 AM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
As long as they only ban it in their own code and don't ban it from VC++, that's fine with me.
"I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008
"the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010
I bet another problem that MS must content with here is intentional sabotage, which shady use of memcpy() is probably easy to do and hard to detect. So you take the gun out of your potentially disgruntled (or whatever) employee's hand, that makes sense.
Of course software for MS is always distributed pre-compiled (isn't it), so it will be impossible to enforce such a restriction*, but removing the option from everyone's fav compiler will have some effect, which is why I imagine they would go so far as to say "Sorry, no choice on this, we just can't trust you kids!". I was under the impression that they were gradually trying to move completely away from C for basically this reason: it's prone to abuse, and they cannot exercise control over it the way they can say, C#. Or F#, or whatever else is lined up in that pipe.
* related question: do you have to provide MS with your source in order to get that "officially approved" thing that windows warns about?
Last edited by MK27; 09-09-2009 at 07:42 AM.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
No. The Logo Program doesn't require the vendor to share the source code with Microsoft (at least for software development. I don't know about drivers). On the other hand, it means that Microsoft may share some of its code through the Shared Source Initiative.
The Logo Program mostly establishes requirements in terms of operating system integration in the areas of security, stability and respecting the operating system standards. It's not concerned with how this is done. Just that it is done.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
So in fact you can continue using memcpy(), compile however you wish, and everything will be fine...for now
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
Yeah. Because we, the highly educated, well payed, civilized people could not possibly make mistakes. I for one was born totally flaw-free because after all, I was born into the western civilization. /facepalmI suspect that it's not the programmers in the developed nations that have problems with the 'unsafe' functions, its the 3rd world programmers that work for $5 a day and have a 6th grade education that mess things up.
hth
-nv
She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."
When in doubt, read the FAQ.
Then ask a smart question.
Actually, I don't believe there need to be any security flaws in my opinion. There are two reasons why security flaws could occur:
1. Some programmer screwed up at a rule that's easily established.
2. Two programmers miscommunicated.
Now for the 1st reason: just check the buffers. Check the input. Check for NULL variables. Sorry, but with a few more if's, most vulnerabilities can be avoided. All vulnerabilities like these I've seen (And I've seen a LOT) are because coders are trying to be more clever than they really are or simply use functions they don't know how to use.
Now the 2nd reason: these are a bit harder, where both programmers assume the other person would check for something but neither of them does. That's why there needs to be good communication. If there isn't, one of the programmers screwed up. If there is, then one of the programmer used a function he doesn't know how to use (see 1).
If I code alone, I claim to be able to do anything without any vulnerabilities in it. Sure, it takes a few looks at the manual once in a while to be sure that the string is always 0-terminated or similar.
