Such as? (except the field width, which scanf can do, too)But it isn't. It performs additional security checks that scanf doesn't.
That is not true if you are actually using scanf_s's "security feature" of adding a field width for every %s. If you are just using it as scanf, might as well just use scanf.I suggest not changing it. For standards compliance, all they have to do is add #define scanf_s scanf.
I can't details exactly, because I don't know. But the link mentions "typical" enhancements the secure versions have.Originally Posted by cyberfish
And even if it were just a plain old scanf call, I'd still use scanf_s to get rid of warnings.
The standards committee doesn't seem to care about security stuff. If it did, we wouldn't be in this mess in the first place!
As it stands now, Microsoft is filling the gap that the standards committee hasn't.
Bwhahaha. Just like they "filled the gap" that JAVA had?
Quzah.
Hope is the first step on the road to disappointment.
Funny, I use /D_CRT_SECURE_NO_WARNINGS to get rid of them.
The problem with scanf_s() and its ilk is that it leads people to believe that all they need to do is call this "secure" function and they will magically have security. It's still possible to pass an incorrect buffer size and get an overflow anyway.
Input validation is always necessary. Having a set of functions which are deemed "more secure" than some other functions encourages people to be lax and not think about the issues.
As far as the standards committees not considering security, why should they?
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
They are only warnings in in the MS compiler. It's the only implementation that has those functions.I can't details exactly, because I don't know. But the link mentions "typical" enhancements the secure versions have.
And even if it were just a plain old scanf call, I'd still use scanf_s to get rid of warnings.
If there are "security enhancements" that you don't need to change your code to benefit from, why don't they just implement scanf with scanf_s?
Note that no one has pointed out any real benefit with those _s functions, yet.
That said... I believe in conspiracy theory in a lot of things...
That doesn't mean you shouldn't use the more secure function (think gets vs fgets).Having a set of functions which are deemed "more secure" than some other functions encourages people to be lax and not think about the issues
That being said, I wouldn't use a non-standard function when a standard one exists which does the same thing. In this case, I would just use scanf().
Obviously no function should be used which doesn't allow you to specify the buffer size. The deceptive thing about scanf_s() is that it seems to imply that there is no way to do that with plain-old scanf() -- and yet there is.
The point though, is that just because you have to specify the buffer size doesn't mean you can't get it wrong anyway.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
True, they have made a lot of poor things. Yet, at least we can choose to use them or not.
Anything that is more safe is better in my book.
Just because it's more secure, it doesn't mean it encourages people to be more lazy. I rather think of as gets vs fgets. And this applies not only to buffer size (which there are a number of, such as strcpy_s), but anything security-related, standard or not.
Because it's a HUGE problem in today's world?As far as the standards committees not considering security, why should they?
It just shows that the C standards committee doesn't really "care" about modern systems in my book.
I tend to consider a few more things...Anything that is more safe is better in my book.
like standard compliance, practical portability (I don't really mind if it's not standard but is implemented by all known implementations), and whether the same functionality can be provided with standard functions (if not, whether it is worth it to deviate from standard).
Unfortunately, for this case, they ALL suggest sticking with standard functions. scanf_s has no benefit except silencing 1 Microsoft compiler's pointless warning.
I have considered portability too. All you need is a #define scanf_s scanf on non-Microsoft compilers.
Unless you are using some extended functionality which I have no idea what it is. Microsoft is bad at documenting such things, but it's better than getting rid of ALL warnings or adding annoying pragmas to get rid of a temporary warning.
Or you can define _CRT_SECURE_NO_WARNINGS to get rid of it on MS compiler. scanf_s is not any better than scanf if you don't supply the buffer size parameters, even on the MS compiler. So why not just use scanf?I have considered portability too. All you need is a #define scanf_s scanf on non-Microsoft compilers.
If you DO supply the buffer size parameters, "#define scanf_s scanf" won't work anymore. And the buffer size can also be supplied to the standard scanf...
And silence a lot of other problems? Doesn't sound like a good solution to me.
I have no experience with the MS compiler, but is there no way to just turn off this warning?
Thus:I have no experience with the MS compiler, but is there no way to just turn off this warning?
#pragma warning( disable: nnnn );
where nnnn is the warning number
For portable code, this should be wrapped in a conditional block for the ms compiler
"A lot of other problems"? Microsoft's warning doesn't even mention why x was deprecated in favor of x_s, so there is no silencing of any issues regardless, it's merely an authoritative tenet. The macro doesn't remove any other warning, either, according to their docs.
