Poor buffer handling is implicated in many security issues that involve buffer overruns. The functions defined in Strsafe.h provide additional processing for proper buffer handling in your code. For this reason, they are intended to replace their built-in C/C++ counterparts as well as specific Microsoft® Windows® implementations.
Ever the one to embrace and extend Microsoft now targets the good old C std strings library. This is a minor thing when compared to what they've done to most every other programming language in the context of .NET . Still, it'd be interesting to see if the C community accepts the convention of the HRESULT function return value.
These functions are easily implemented either by wrapping the functions in the standard library, or writing them from scratch (in either case, it's a simple textbook exercise). If other people than Microsoft want to do so in their own projects (which is probably a good idea, although there exists lots of alternative "safer" C string libraries already), then they are probably going to choose another naming convention. I doubt you will see this in any C standard soon, and I also think it's wrong to call this extend and embrace, it's simply good software engineering.
The one I learned and later wrote again allocated space for the string and the length. The pointer was aimed at the first character. The length field was "above" the pointer and the 0 terminated characters were below the character. This made it easy to take advantage of the std functions in the implementation of the safer library.
strlcpy and strlcat - consistent, safe, string copy and concatenation
strlcat() and strlcpy() have since been adopted by the OpenBSD, FreeBSD, NetBSD, and Solaris libc libraries. Surprisingly (?) GNU glibc has does not provide these functions..
Embrace and extend was definitely tongue in cheek especially when you compare this to what Microsoft has done in the context of .NET . Still when you consider the "standard" safe string functions have been available for a while (as Chris has shown) and yet Microsoft has elected to create its own variant, you get my drift.
The technique proposed by Patrick is the same one used by COM basic strings (BSTR). The upside is obvious - you can use these strings wherever a "standard" string is expected. On the downside type safety is lost because you can't tell them apart from "standard" strings. This problem has bitten many a COM programmer on the arse.
Second, notice that the type safety angle is crucial here. You can process strings not via their access routines but simply by giving array subscripts. Since the language doesn't do range checking you are doomed. Cool langugaes (e.g., Ada) allow you to work on slices of arrays, and still enjoy range checking etc.
(By the way, Ada only supports simple, one dimensional slices. In PL/I you could do much more elaborate things - and obfsucate your code to your heart's desire).
Ah, to check or not to check that is the question. STL explicitly decided not to do range checking because it was assumed that C++ programmers would not accept the performance overhead, minor as it may be (and a smart compiler may be able to remove most of this overhead as well). Still std::string does do range checking when asked to.
And yes, we all know that C/C++ arrays are evil (so sayth the FAQ).
I know Microsoft always favors backwards compatibility over safety, but GNU glibc and Linux could probably get away with dropping some backwards compatibility. If GNU is Not Unix, shouldn't it be encouraging known best practices rather than following dangerous Unix "standards"?