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

The link doesn't seem to be working but (if you're talking about what I think you're talking about) that isn't Joel's idea. It's Apps Hungarian notation which was invented in the 70s at PARC.

Although, IMHO, it's just a poor attempt to compensate for a weak type system (Type Synonyms, etc. are a much better fix, since then your compiler can guarantee that you are doing the right thing).

Worth noting that strcpy_s actually is safer than strcpy.

Heh, I like that article...the description of "i=j*5" in C++ should probably be on the first slide of any C++ programming class. :)

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

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.

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