Anyone know where we can get header files and libraries for the Windows "string-safe" functions? (StringCbPrintf(), StringCchPrint(), StringCbPrintfEx(), StringCbVPrintf(), etc.)
MSDN says (http://msdn.microsoft.com/en-us/library/ff468908%28v=VS.85%29.aspx) we should use these instead of wsprintf(), etc.
The string safe functions are not exported by any library, they are inline code in the SDK headers (Strsafe.h) so they would need to be rewritten from scratch for MASM. However in Windows 8 I noticed that a few of them are available in kernel32.dll as exports.
try this post by Yves...
http://www.masm32.com/board/index.php?topic=8022.msg59040#msg59040
We have a dedicated thread here (http://www.masm32.com/board/index.php?topic=11432.msg85150#msg85150).
Attached the strsafe.h file from Koders Code Search (http://www.koders.com/c/fidBB1352C87E80371BB5BDDEC6FB4A8DAD6159848F.aspx?s=http#L10).
Wasn't aware that they had been compiled for Pelle's package, interesting but still a pointless set of routines since the actual validation routines depend heavily on the compiler. For example the memory validation simply checks to see if cchDest is between 0 and STRSAFE_MAX_LENGTH (cchMax). It does absolutey nothing to ensure that the memory buffer allocated is large enough, the compiler takes care of that. So from the standpoint of assembly they are not "safe" at all and suffer even more risk of buffer overflow exploits than the lstrxxx functions (if that's possible). At least that was my take when I had looked (briefly) at building an assembly version of the library a few years back.
Quote from: donkey on December 22, 2011, 02:43:13 AMIt does absolutey nothing to ensure that the memory buffer allocated is large enough, the compiler takes care of that. So from the standpoint of assembly they are not "safe" at all
Yes indeed - it just moves the problem elsewhere. And they are sloooow...
Here is a safe
and fast example:
include \masm32\MasmBasic\MasmBasic.inc ; Press F6 to assemble & link (http://www.masm32.com/board/index.php?topic=12460)
Init
Let esi="This is a string argument"
Let Mid$(esi, 1)="These are strong arguments"
Inkey "Esi=[", esi, "]"
Exit
end start
Esi=[These are strong argument]Pure
Masm :wink
There is "MSDN" for StringCatExWorkerW...?
as Yves states, the "worker" functions are for internal use - do not use them
In any case, it's all there in the strsafe.h header file, so you can pick and choose what you want. Of course, you'd have to convert it to assembly language; not impossible, but looks like a fair amount of work.
But mostly because of "donkey's" comments here, I've lost whatever enthusiasm I had for using these functions anyhow. Since I'm not writing any code that needs worry about security, there's really no upside to using this bloated code instead of the good ol' reliable C-equivalent functions.
the msvcrt library has it's advantages, that's for sure
many of the functions are well behaved, thoroughly tested, and pretty fast
another upside - they are "built-in" to the OS, essentially, because all windows machines have them
you don't have to carry all that code around with you :P
there are several cases where Hutch's masm32 library is faster, however
and - where he couldn't top the msvcrt functions, he gives you wrapper functions and macros to save you coding time
I have always chuckled at the notion that you need "string safe" functions. There is a perfectly good way to do this in a very reliable manner, use any of a mountain of string length algorithms and get the required buffer size FIRST, Allocate that much memory OR MORE and you are garranteed safe for the buffer size.
The distinction is between algorithms and objects, a "string safe" function is more like an object in that it is supposed to hold you hot little hand so you don't do something stupid where algorithm design allows you to construct your own SAFE function without the assumptions that you are that stupid that you cannot check the length yourself.
Quote from: hutch-- on December 22, 2011, 08:15:25 PMuse any of a mountain of string length algorithms and get the required buffer size FIRST, Allocate that much memory OR MORE and you are garranteed safe for the buffer size
Hutch,
You are perfectly right, and that is how the Let example above works. Nonetheless, it is truely amazing how often "professional" apps from Microsoft and Adobe and others have shown me a GPF - less often in recent years, I must admit. Yet, it seems as if the language C induces programmers to ignore the rules. Assembler is so transparent that you cannot pretend not to see that a buffer overflow is looming ahead.
In any case the strsafe libs are useless, fullstop.
Something I posted in 2005 about using the strsafe functions in masm.
http://www.masm32.com/board/index.php?topic=1207.0
I agree they aren't needed if a person knows what they are doing. Microsoft was really pushing them back then.