

List of C functions banned by Microsoft (in SDL) - dchest
http://msdn.microsoft.com/en-us/library/bb288454.aspx

======
twoz
So instead of using the unsafe strcpy function, you now use the safe strcpy_s.

Joel had some thoughts on this a while ago (2005); prepending s for safe and
us for unsafe to variables.

<http://www.joelonsoftware.com/articles/Wrong.html>

~~~
tptacek
Worth noting that strcpy_s actually is safer than strcpy.

------
billswift
Bruce Schneier posted about one particular function that was banned - memcpy.
[http://www.schneier.com/blog/archives/2009/05/microsoft_bans...](http://www.schneier.com/blog/archives/2009/05/microsoft_bans.html)

~~~
neilc
The fact that he calls it "Memcopy()" doesn't exactly lend confidence. I don't
really see the problem with memcpy() anyway: memcpy() copies exactly the given
number of bytes. If the programmer gets the source buffer length wrong with
memcpy(), they are just as likely to get the destination buffer length wrong
with memcpy_s().

And banning strlen() is just idiotic. The differences between strlen() and
strnlen_s() (the suggested "safe" replacement) are apparently: (1) strnlen_s()
takes a maximum string length argument (2) strnlen_s() returns 0 on a NULL
pointer. #1 is pointless (what if the string has no predefined maximum
length), and will just lead to programmers hardcoding inappropriate constants.
#2 is potentially hazardous, because it hides problems: NULL and the empty
string are _not_ the same thing, so having strnlen_s() return 0 for both cases
is misleading.

------
jrockway
It's nice that Microsoft, OpenBSD, and GNU all have their own incompatible
versions of safe string manipulation functions. We wouldn't want anyone to
write portable code...

