<ctime> localtime deprecated in VS 2010?

This is a discussion on <ctime> localtime deprecated in VS 2010? within the C++ Programming forums, part of the General Programming Boards category; I received a compiler warning about localtime in Visual Studio which suggested I used localtime_s. Perhaps you can clarify this ...

  1. #1
    Registered User
    Join Date
    May 2010
    Posts
    178

    <ctime> localtime deprecated in VS 2010?

    I received a compiler warning about localtime in Visual Studio which suggested I used localtime_s. Perhaps you can clarify this for me in addition to a quick google search which suggested ignoring the warning and that perhaps Microsoft will correct the errors of their ways.

    What is your opinion? I'd like to know.

  2. #2
    Registered User
    Join Date
    Mar 2010
    Posts
    535
    They've "deprecated" tons of functions: Security-Enhanced Versions of CRT Functions

    I don't think everything on the list will bring up a deprecated warning (e.g. I don't think I've ever been warned off using printf) - but quite a few do. I don't think "deprecated" was the right choice of warning - since they apparently have no plans to remove support for them, and they're merely encouraging us to use the security enhanced ones.

    Looking at the changes they've made in their *_s versions of the functions, they seem sensible and probably useful. That said, I'd personally ignore the warnings and the new functions -- I don't want to get into habits of coding that only work on one platform. If I was only working on Windows with MSVC I'd consider using them.

    I was interested to see that one of these changes is in C11 -- C11 removes the infamous gets(buf) and replaces it with gets_s(buf, len). Bout time!

  3. #3
    Registered User
    Join Date
    May 2010
    Posts
    178
    Quote Originally Posted by smokeyangel View Post
    They've "deprecated" tons of functions: Security-Enhanced Versions of CRT Functions

    I don't think everything on the list will bring up a deprecated warning (e.g. I don't think I've ever been warned off using printf) - but quite a few do. I don't think "deprecated" was the right choice of warning - since they apparently have no plans to remove support for them, and they're merely encouraging us to use the security enhanced ones.

    Looking at the changes they've made in their *_s versions of the functions, they seem sensible and probably useful. That said, I'd personally ignore the warnings and the new functions -- I don't want to get into habits of coding that only work on one platform. If I was only working on Windows with MSVC I'd consider using them.

    I was interested to see that one of these changes is in C11 -- C11 removes the infamous gets(buf) and replaces it with gets_s(buf, len). Bout time!
    So it is just about security then? I shall take your advice and agree I do not want to have to adjust just to Microsoft recommendations.

  4. #4
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,485
    Quite a few of the so-called "safe" functions are just as dangerous as the "unsafe" functions in the hands of programmers who don't know what they're doing. How many times have we seen on this forum examples of using fgets(), which is a safe function when used correctly, being passed uninitialised pointers and mis-matched array sizes.

    You could argue that the _s could lead to a false sense of security, causing anyone looking for bugs to spend less time examining that particular function call for potential issues.

    Most of them can be implemented with very simple wrapper code which allows you to retain maximal portability.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  5. #5
    Registered User
    Join Date
    Oct 2006
    Posts
    2,349
    and probably the biggest problem with the _s functions is that they lock you into the microsoft toolchain.

  6. #6
    Registered User
    Join Date
    Jun 2005
    Posts
    6,247
    Quote Originally Posted by Imanuel View Post
    So it is just about security then?
    They describe it as security enhancements. It is actually about reducing the chances of buffer overflows and other memory related problems.

    While it is true that memory related problems contribute to a lot of security concerns, and using safer functions can have a security benefit, life is more complicated than that. Not all memory-related concerns contribute to security concerns, but it is important to address memory-related concerns regardless of their security impact. And a lot of real-world security concerns related to broader aspects of software design and architecture, even if memory usage is ostensibly "safe".

    Not to mention the fact, as mentioned by Salem, is that programmers are often unduly complacent when using "safe" methods.

    Personally, I would stick to standard functions, and keep alert. Using a potentially dangerous function carefully is less risky than using an ostensibly safe function in a dangerous manner. Although, the biggest risk is careless programmers using dangerous functions in a dangerous manner, and believing they are being safe.
    Last edited by grumpy; 12-29-2012 at 06:09 PM.
    Right 98% of the time, and don't care about the other 3%.

  7. #7
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,538
    I would say that it is better to use the "safer" functions then the "non-safe" ones. I'm basing that on the fact that it's easier to get the size of a buffer correct than make all the proper security checks manually. Either way, if you mess up, you are in equally serious trouble.
    It's a small price to pay since it's easy to write wrappers to gain portability, and security is very important.
    Of course, the best way would simply be to not use these functions, which brings me to ask why you are trying to use them in the first place?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #8
    Registered User
    Join Date
    Jun 2005
    Posts
    6,247
    Quote Originally Posted by Elysia View Post
    I would say that it is better to use the "safer" functions then the "non-safe" ones.
    All other things being equal, that is true. Unfortunately, in the real world, the other things are not safe.

    The problem with a lot of safe functions is a very human one. The designer of the safe function assumes the user of the function will always comply with some (often unstated) rules. Because the function is advertised as "safe", programmers using it are complacent, use the function in an unsafe manner and, because of a belief the function is safe, do not verify correct behaviour. A problem is introduced, often to be found by an end user who (if you're lucky) submits a bug report and (if you're unlucky) chooses a competing product that does not exhibit the bug. Bug reports are closed out as "spurious" or "unfounded" by the programmer because of the complacency associated with having used the "safe" function.

    Having seen such a phenomenon in association with development of a safety-critical system (i.e. one that would kill or maim people if it malfunctioned), I suggest more is needed than a claim that of a function being "safe" to justify its use.

    If you're going to use "safe" functions that still needs to be part of a disciplined process. Given a choice between a disciplined use of an "unsafe" function, and an undisciplined use of a "safe" function that meets the same purpose, I'll choose use of the unsafe function. Unfortunately, the overt use of "safe" functions often has a strong positive correlation with increased programmer complacency.
    Right 98% of the time, and don't care about the other 3%.

  9. #9
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,538
    If the purpose of the usage of the functions are to simply reduce the number of security issues, I would say using the "safe" functions is a good way to do it. If you do it wrong, then you are not worse off than using the "unsafe" functions.
    In safety critical systems, I would agree with you that you can't just use and forget. You need to somehow properly verify that your code truly and properly contain no security bugs. Presumably, you have other tools then, too, to verify such things, though.
    Heck, that you would be a very good idea in any project development, but for hobby projects, that seems somewhat difficult...
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,299
    Many of the safe ones have overloads that work out the buffer size for you, as in the case where they are passed a local array. In those cases you don't have to change anything besides adding the _s.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Windows 7 RC, Visual Studio 2010 Beta, Office 2010 beta, anyone in?
    By indigo0086 in forum A Brief History of Cprogramming.com
    Replies: 2
    Last Post: 05-20-2009, 01:57 PM
  2. localtime curiosity
    By rjhanby in forum C Programming
    Replies: 5
    Last Post: 03-20-2009, 10:15 AM
  3. localtime
    By cnu_sree in forum C Programming
    Replies: 1
    Last Post: 06-06-2007, 11:19 PM
  4. localtime and time
    By l2u in forum C Programming
    Replies: 5
    Last Post: 07-24-2006, 12:10 PM
  5. getting LocalTime
    By Devil Panther in forum Windows Programming
    Replies: 2
    Last Post: 06-20-2003, 05:41 AM

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