Printable View
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.
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.Quote:
Originally Posted by smokeyangel
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.
and probably the biggest problem with the _s functions is that they lock you into the microsoft toolchain.
They describe it as security enhancements. It is actually about reducing the chances of buffer overflows and other memory related problems.Quote:
Originally Posted by Imanuel
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.
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?
All other things being equal, that is true. Unfortunately, in the real world, the other things are not safe.Quote:
Originally Posted by Elysia
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.
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...
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.