lazy coding standards turning away classic functions?

This is a discussion on lazy coding standards turning away classic functions? within the General Discussions forums, part of the Community Boards category; Unsafe at any speed: Memcpy() banished in Redmond • The Register So correct me if I'm wrong here... Microsoft is ...

  1. #1
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,691

    lazy coding standards turning away classic functions?

    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?
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  2. #2
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    I think this probably means that everybody is supposed to use the "secure" versions of these functions.

    Developers 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.
    Yawn. And as it turns out gcc does not support some Microsoft-specific non-standard extension, go figure
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #3
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    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.

  4. #4
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    Quote Originally Posted by EVOEx View Post
    The solution? Keep your software easy to port by not using Visual C++ at all.
    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).

    Quote Originally Posted by EVOEx View Post
    Use a real compiler.
    I hope you aren't suggesting building our MS Windows code with MinGW...

    Quote Originally Posted by EVOEx View Post
    Actually, I only code for linux anyway.
    Ah. Ok. That explains it then.
    Last edited by Mario F.; 09-09-2009 at 04:39 AM.
    The programmers wife tells him: Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.
    The programmer comes home with 12 loaves of bread.


    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.

  5. #5
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by brewbuck View Post
    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 figure
    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.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  6. #6
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    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

  7. #7
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,763
    >Programmers now have to cut bread with origami knives?

    Yeah, let's not overreact or anything.

  8. #8
    In my head happyclown's Avatar
    Join Date
    Dec 2008
    Location
    In my head
    Posts
    391
    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.

  9. #9
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    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 06:04 AM.
    The programmers wife tells him: Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.
    The programmer comes home with 12 loaves of bread.


    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.

  10. #10
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    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

  11. #11
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by abachler View Post
    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.
    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 08: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

  12. #12
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    Quote Originally Posted by MK27 View Post
    Of course software for MS is always distributed pre-compiled (isn't it), so it will be impossible to enforce such a restriction*
    [...]
    * related question: do you have to provide MS with your source in order to get that "officially approved" thing that windows warns about?
    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.
    The programmers wife tells him: Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.
    The programmer comes home with 12 loaves of bread.


    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.

  13. #13
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Mario F. View Post
    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.
    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

  14. #14
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,139
    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.
    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. /facepalm
    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.

  15. #15
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    Quote Originally Posted by nvoigt View Post
    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. /facepalm
    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.

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. coding help? (functions)
    By believe in forum C Programming
    Replies: 2
    Last Post: 06-03-2007, 12:54 PM
  2. comment on my coding style and if i use functions well
    By Unregistered in forum C++ Programming
    Replies: 14
    Last Post: 03-09-2002, 07:24 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21