Thread: Switch Problem

Originally Posted by cyberfish

I'm gonna say it's just another Microsoft attempt at vendor lock-in.

But it isn't. It performs additional security checks that scanf doesn't.

So I suggest changing it back to scanf for standard compliance (unless there is something I missed).

I suggest not changing it. For standards compliance, all they have to do is add #define scanf_s scanf.

Originally Posted by Elysia

But it isn't. It performs additional security checks that scanf doesn't.



I suggest not changing it. For standards compliance, all they have to do is add #define scanf_s scanf.

And why standards cometee should follow Microsoft and not the opposite?

Originally Posted by cyberfish

Such as? (except the field width, which scanf can do, too)


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 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.

Originally Posted by vart

And why standards cometee should follow Microsoft and not the opposite?

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.

Originally Posted by Elysia

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.

Originally Posted by Elysia

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.

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?

Originally Posted by quzah

Bwhahaha. Just like they "filled the gap" that JAVA had?
Quzah.

True, they have made a lot of poor things. Yet, at least we can choose to use them or not.

Originally Posted by brewbuck

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.

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.

As far as the standards committees not considering security, why should they?

Because it's a HUGE problem in today's world?
It just shows that the C standards committee doesn't really "care" about modern systems in my book.