List of useful security libraries

I was asked last week for a list of “drop-in-and-more-secure” replacements, created at Microsoft, for C/C++ functions and constructs.

So here’s a list:

IntSafe (C safe integer arith library)

SafeInt (C++ safe integer arith template class)

Secure CRT (C runtime replacements for strcpy, strncpy etc etc)

StrSafe (C runtime replacements for strcpy, strncpy etc etc)

Comments (7)

  1. James says:

    That SafeInt class template (not template class) has got to be the worst bit of C++ I’ve seen in a while. Didn’t that guy read Effective C++ or myriad other things? There’s got to be something unsafe about bypassing the short-circuit evaluation for logical operators. The author doesn’t justify his suspect choices, so I’ll assume he doesn’t know what he’s doing.

  2. David LeBlanc says:

    BTW, Michael should have posted the link to the 2.0 version of the class, which is a fair bit cleaner, and is also posted on MSDN.

    There is something unsafe about bypassing short-circuit evaluation for logical operators. But if you’re going to pass a SafeInt to something that needs a bool, you’re going to end up with this. It is one of the design trade-offs, and this one was considered very early on. The only time this will really bite you is in the case of:

    if(func() && func2())

    where is isn’t valid to call func2 unless func has succeeded. That’s not a typical usage scenario for SafeInt, hence the design decision.

    There’s several hundred lines of documentation and comments in the class – perhaps I missed that point.

    Funny you should mention Meyers’ books – they’re among my favorites, and Scott wrote me to let me know he really liked this class. If you take a look in the comments, you’ll see where I made changes based on his input.

  3. David LeBlanc says:

    The newer version of SafeInt (2.0), and the associated article is at, and a direct link to the code is

    BTW, an easy work-around to ensure short circuiting works as you want is to write clean code like so:

    Instead of:

    if(SafeInt<int>(x) && SomeFunc())


    if(SafeInt<int>(x) != 0 && SomeFunc())

    This is nicer, more readable code, and the != operator does return a bool, this the && operator then works exactly as you expect. Another work-around would be to do this:

    if((bool)SafeInt<int>(x) && SomeFunc())

    My personal opinion is that if you write code that depends on short-circuiting to work correctly without side-effects, you’ll find that others will have a hard time maintaining your code.


  4. A couple of people have asked about the relationship between /GS, SAL and ASLR in Windows Vista. Here’s…