Page 1 of 1
9 Replies - 37518 Views - Last Post: 31 August 2014 - 01:35 PM
Posted 24 May 2009 - 12:40 AM
So, what's so great about fopen_s?
Replies To: fopen_s
Posted 24 May 2009 - 12:51 AM
if you're using dev cpp and a c program (because I've met fopen_s too)
if it doesn't work with it maybe fopen_s is really better , although I think it's a heavy func.
Posted 24 May 2009 - 02:24 AM
Welcome to windows. Breaking hearts and standards wherever is goes.
A number of the list _s functions seem to accept an extra max size parameter. They do extra checks against things like buffer overflows. Microsoft has determined that core functions in the C library are part of their security woes. Notably, they recently announced that memcpy is right out.
Posted 24 May 2009 - 02:58 AM
It seems like banishing old, unsafe operation like that could only be good for developers. But seeing how this comes from Windows, it makes me think if this is too good to be true. Is there any bad thing about this "secure" standard library?
Posted 24 May 2009 - 07:11 AM
Well, it's not a standard library, it's a Windows library.
The only bad thing is that my standard ISO functions now throw compiler warnings. If you are a good programmer and make happy secure Microsoft code, getting that code out of Windows can take a little work.
Some aren't too hard:
#ifndef WIN32 #define localtime_r(tp, ts) *ts = *localtime(tp)
#ifdef WIN32 WSACleanup(); #else close(ConnectSocket); #endif
Some are harder. Also, such includes made for damn ugly code.
Posted 31 August 2014 - 01:33 PM
I'm NOT saying to avoid the newer "safe" functions. As for me, I often judge that my particular use of a standard function is safe and simpler...or at least "safe enough" and "not more complicated". To get rid of the compiler warnings you can put
#pragma warning (disable: 4996)
before the "offending" line of code.
Note: 4996 is the error number to disable. And the compiler's warning message will include this number.
This seems to work for me in Visual Studio.