Thread: lazy coding standards turning away classic functions?

  1. #31
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by adeyblue View Post
    Introducing StrSafe, by our definition it's no safer than what you've got now. I guess they forgot it's built on top of the "banned" CRT functions. Well, unless you happen to know the magical mystery define that's not documented anywhere.
    I don't know what you mean here, adey.

    This is essentially the differences between strSafe and Safe CRT

    Headers: One (StrSafe.h) vs. Numerous (various C runtime headers)
    Library Version Available: Yes on both cases
    Inline Version Available: Yes for StrSafe
    Industry Standard: Possibly for the Safe CRT. Depends on the end result of the C Library TR 24731-1 (pdf link). Personally I suspect not.
    Kernel Mode: Yes for the StrSafe.
    Objectives: Buffer overruns for the SafeStr and Buffer overruns plus anything else for the Safe CRT.

    Meanwhile both options overlap in many of the banned APIs which should give you some freedom of choice. To choose one over the other is a matter of looking at what they offer from the list above (also available, and more complete, at the Ban list address). Not anything else.

    But essentially, the Safe CRT option (the one you see on any VC++ 2005 and 2008 versions and that annoys you with those "deprecated warnings) doesn't include any special magic either. None of the appointed replacements are full-proof solutions. None of them plan to be.

    There's however a few issues they are fixing for the next version, 5.0. For instance, strlen and friends presence there (table 19) doesn't make any sense unless it is meant for sensitive server operations under anonymous connections (to avoid non-terminating string attacks for instance). As such, these functions are planned to be removed entirely from the banned list.

    ...

    Look, IMHO the thing is twofold:

    1. You have a clear problem of language. Words like "Banned", "Deprecated" and "Safe" are terrible choices. This is bringing a lot of confusion to anyone who, rightfully so, doesn't want to dig deeper into all this crap. Words like these are very powerful and have a very specific meaning in the context of software development. However they are being used rather irresponsibly by Microsoft itself. At least that's my opinion. First because only in the context of the SDL are these functions "Banned". Second because a compiler doesn't "Deprecate" a standard. Third because the solutions aren't "Safe".

    2. Not without fundamental changes to how C++ compiles would it ever be possible to create fully full-proof versions of these functions. This is most probably never going to happen. These solutions are to be understood once and for all in this context. They aren't safe. They are safer. And they are safer simply because on the majority of cases they introduce the element of size in the function signature, forcing the programmer to give it a thought. Not because of any new compilation magic. Within the context of the SDL however that's an entirely different matter. Supported by these functions and the Process Template parameters and definitions, you have the tools to then run all sorts of code analysis tests to guarantee your code safety. That's where these functions may trully shine. But that doesn't mean errors won't still creep in. Processes aren't always respected, reports aren't always read or correctly interpreted, schedules are often tight and it's the Testing phase that usually gets swollen up, people will keep making mistakes. One can expect to reduce the problems. Not solve them.

    ...

    When I started following this a little more close in the beginning of the year, this issue became quite apparent to me just from reading some of the replies on some of the Microsoft representatives blogs. When you have programmers asking if the size parameter includes the target buffer null terminator, it just becomes crystal clear not only the solutions aren't meant to solve the problem (instead, to minimize it), but also anyone who makes these type of question really needs to use these functions.
    Last edited by Mario F.; 09-09-2009 at 09:25 PM.
    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.

  2. #32
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    I have talked to people who used to work in the AV industry and they could not use un-safe functions due to buffer overruns and the like. This is one reason why I think MS added the 'safe' versions to their compilers so they could satisfy their users. Honestly most of MS does not use MSVS so it would gain them nothing to add these functions for internal purposes.
    If you are writing AV, Firewall, or OS's I would think using the 'safe' functions could reduce the types of attacks that could be performed against your product so you certainly would want to use them.

    You can easily turn the warnings off in MSVS to allow use of what they call 'deprecated' CRT functions. The only beef I have with all of it is the way it was implemented. The naming scheme is just horrific and it could have very well been done under the hood via some CRT define. If safe was defined it could have resolved to the so-called safe version and if not it would have resolved the standard CRT version. But I didn't implement it and no one asked me so it is a moot point. I also disagree with the terminology being used as if the 'safe' function is somehow 'safer' in the hands of an idiot. Calling the standard CRT 'deprecated' is also a huge stretch. How can you deprecate a standard without first consulting the committee overseeing the standard? Deprecated normally means do not continue to use b/c in later versions it may not work. This cannot be what they mean in the context of the CRT functions. If it does mean they are not going to support the standard CRT in future versions of MSVS then they should probably re-think that decision before implementing it. So far 'deprecated' in this means 'deprecated' in as much as it pertains to what MS really wants.
    Last edited by VirtualAce; 09-09-2009 at 09:29 PM.

  3. #33
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Bubba View Post
    If you are writing AV, Firewall, or OS's I would think using the 'safe' functions could reduce the types of attacks that could be performed against your product so you certainly would want to use them.
    This makes it sound like you are somehow less responsible for security problems in your software if you stick to the "safe" functions. "But I used memcpy_s()! It's not my fault my application is exploitable, I am using safe functions."

    I think this is exactly the problem. People are confusing the use of "safe" functions with actual safe coding. Calling one function instead of some other function doesn't make your code secure. You have to mindfully write secure code.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  4. #34
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by Bubba View Post
    The only beef I have with all of it is the way it was implemented. The naming scheme is just horrific and it could have very well been done under the hood via some CRT define. If safe was defined it could have resolved to the so-called safe version and if not it would have resolved the standard CRT version.
    Unfortunately, the safe versions require additional information that can't 'safely' be extracted using only the prototypically available arguments of the 'unsafe' functions.

  5. #35
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Bubba
    Calling the standard CRT 'deprecated' is also a huge stretch. How can you deprecate a standard without first consulting the committee overseeing the standard? Deprecated normally means do not continue to use b/c in later versions it may not work. This cannot be what they mean in the context of the CRT functions. If it does mean they are not going to support the standard CRT in future versions of MSVS then they should probably re-think that decision before implementing it. So far 'deprecated' in this means 'deprecated' in as much as it pertains to what MS really wants.
    Actually, the MSDN documentation is quite clear that by "deprecated" they mean "not recommended by Microsoft" rather than "marked for future removal and thus should be avoided". To use their own language, this usage of "deprecated" is deprecated. You probably would also be correct to state, if you so wish, that those "secure" functions are deprecated. When challenged, you can just state that you do not recommend them.
    Last edited by laserlight; 09-10-2009 at 09:17 AM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #36
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by laserlight View Post
    Actually, the MSDN documentation is quite clear that by "deprecated" they mean "not recommended by Microsoft" rather than "marked for future removal and thus should be avoided".
    They should really call these functions unappreciated then
    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

  7. #37
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    This makes it sound like you are somehow less responsible for security problems in your software if you stick to the "safe" functions.
    I also disagree with the terminology being used as if the 'safe' function is somehow 'safer' in the hands of an idiot.
    This is exactly what I'm saying. 'Safe' means nothing if you have a habit of using unsafe practices. But we all know that companies like to spin the software to their customers so they tell them 'oh all of our C++ is 'safe' so our code is that much better'. Most of us just roll our eyes but it is a selling point and it is something concrete by which you can market your product to some consumer as somehow being better than that code which does not use the 'safe' functions.

    In reality those functions do not guarantee safe code and I think all of us here understand that clearly.
    Last edited by VirtualAce; 09-11-2009 at 09:31 PM.

  8. #38
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    Quote Originally Posted by Bubba View Post
    This is exactly what I'm saying. 'Safe' means nothing if you have a habit of using unsafe practices. But we all know that companies like to spin the software to their customers so they tell them 'oh all of our C++ is 'safe' so our code is that much better'. Most of us just roll our eyes but it is a selling point and it is something concrete by which you can market your product to some consumer as somehow being better than that code which does not use the 'safe' functions.

    In reality those functions do not guarantee safe code and I think all of us here understand that clearly.
    Yes, and yes.
    I suppose the only annoyance to me is that they're implying that the depreciated/unappreciated functions are "unsafe", which is entirely untrue.

  9. #39
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Quote Originally Posted by Yarin View Post
    Yes, and yes.
    I suppose the only annoyance to me is that they're implying that the depreciated/unappreciated functions are "unsafe", which is entirely untrue.
    Entirely untrue? gets was deprecated officially for the same reason.

  10. #40
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by whiteflags View Post
    Entirely untrue? gets was deprecated officially for the same reason.
    IMO gets() is a categorically different case since it reads from a file stream, so it is impossible to pre-check the size of the input and use it safely.

    memcpy, on the other hand, works with blocks of memory who's size can be prechecked, and therefore it is possible to use safely.
    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

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, 11:54 AM
  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