SafeInt Issue Tracker Rss Feed

Closed Issue: bug gcc 4.3.2 and 4.4.1 int64_t [8791]

dcleblanc — Thu, 16 May 2013 08:03:30 GMT

i try to use multiply on int64_t

boost::int64_t a=2;
boost::int64_t b=3;
boost::int64_t c;
SafeMultiply<boost::int64_t,boost::int64_t>(a,b,c);

gcc 4.3.2 and 4.4.1 takes compile time error

SafeInt3.hpp: In function ‘bool SafeMultiply(T, U, T&) [with T = long int, U = long int]’:
test1.cpp:233: instantiated from here
SafeInt3.hpp:4995: error: incomplete type ‘MultiplicationHelper<long int, long int, 11>’ used in nested name specifier

Created Issue: nullptr and /CLR [15237]

KeithBurton — Thu, 31 May 2012 06:58:46 GMT

Using Visual Studio 2008 , it is not possible to include the header in mixed CLR and native code because of the definition of nullptr clashes with CLR usage.

Given there is only one use of nullptr in SafeInt3.hpp , defining nullptr seems to be a lot of trouble for dubious benefit.

Commented Issue: integer overflows [14278]

dcleblanc — Fri, 23 Sep 2011 07:14:27 GMT

I've been tracking down some integer overflows in Firefox and seem to have narrowed some of them down to the SafeInt library.

As an example, the "a = -a;" assignment at SafeInt3.hpp:2102 is sometimes invoked while a has value INT_MIN. Of course, negating INT_MIN is undefined behavior in C++98 and C++11.

To reproduce, change the code like this:

if( a < 0 )
{
if (a==INT_MIN) printf ("oops!\n");
a = -a;
fIsNegative = true;
}

Then run MultVerify(). Here is what I get:

[regehr@gamow safeint]$ g++ -O -w TestMain.cpp MultVerify.cpp -o TestMain
[regehr@gamow safeint]$ ./TestMain
oops!
oops!
oops!
oops!
oops!
oops!

This is 3.0.16p. There are some other overflows in SafeInt, please let me know if you are interested in bug reports about them.
Comments: ** Comment from web user: dcleblanc **

This issue should be addressed by the 3.0.17 release. Note to consumers - 3.0.17 is still considered a beta. It is strongly recommended that if you are using a compiler which aggressively optimizes that you also enable (and pay attention to) the warnings that it is removing code.

Commented Issue: integer overflows [14278]

dcleblanc — Thu, 22 Sep 2011 23:36:36 GMT

Thanks for looking into this. I hadn't previously considered -MIN_INT to be something that a compiler would get overly ambitious about optimizing.

At the moment, I think the scope of the problem is largely when MIN_INT is passed as a compile-time constant to SafeInt. We're working on an update that will resolve the problem.

Commented Issue: integer overflows [14278]

regehr — Thu, 22 Sep 2011 15:03:00 GMT

Below, the full list of integer undefined behaviors seen while running *Verify.cpp.

UNDEFINED at <./SafeInt3.hpp, (2102:16)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2120:25)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2148:16)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2166:25)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2252:18)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2258:18)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2269:29)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2305:18)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2311:18)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2322:25)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2356:18)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2367:29)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2400:18)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2411:25)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2448:18)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2465:29)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2499:17)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2505:17)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2516:25)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2565:17)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2571:18)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2582:29)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2629:17)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2635:18)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2646:25)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2679:18)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2690:29)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2718:18)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (2729:29)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (3798:44)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (3826:44)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (3855:36)> : Op: +, Reason : Signed Addition Overflow
UNDEFINED at <./SafeInt3.hpp, (3878:36)> : Op: +, Reason : Signed Addition Overflow
UNDEFINED at <./SafeInt3.hpp, (4539:62)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (4570:62)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (4652:27)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (4678:27)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (4782:36)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (4842:36)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (6519:43)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (6521:25)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (868:34)> : Op: -, Reason : Signed Subtraction Overflow
UNDEFINED at <./SafeInt3.hpp, (878:34)> : Op: -, Reason : Signed Subtraction Overflow

Commented Issue: integer overflows [14278]

regehr — Thu, 22 Sep 2011 03:21:45 GMT

I got SafeInt to malfunction due to this undefined behavior by writing this test code:

void test (__int32 a, __int64 b) {
__int32 ret;
bool res = SafeMultiply (a, b, ret);
if (res) {
printf ("%d * %lld = %d\n", a, b, ret);
} else {
printf ("%d * %lld = INVALID\n", a, b);
}
}

int main (void)
{
test (INT_MIN, -2);
test (INT_MIN, -1);
test (INT_MIN, 0);
test (INT_MIN, 1);
test (INT_MIN, 2);
return 0;
}

Now, watch the answer change as the optimization options are changed:

regehr@home:~/embedded_papers/john/overflow12/safeint$ current-g++ -O1 john_test.cpp ; ./a.out
-2147483648 * -2 = INVALID
-2147483648 * -1 = INVALID
-2147483648 * 0 = 0
-2147483648 * 1 = -2147483648
-2147483648 * 2 = INVALID
regehr@home:~/embedded_papers/john/overflow12/safeint$ current-g++ -O2 john_test.cpp ; ./a.out
-2147483648 * -2 = INVALID
-2147483648 * -1 = INVALID
-2147483648 * 0 = 0
-2147483648 * 1 = INVALID
-2147483648 * 2 = INVALID

This is using today's pre-4.7 G++ snapshot on Ubuntu Linux. Behavior is consistent across x86 and x64.

Basically the current version of SafeInt needs to be compiled with -fwrapv or equivalent in order to function correctly. Of course, not all compilers support such an option.

Created Issue: integer overflows [14278]

regehr — Wed, 21 Sep 2011 20:32:12 GMT

Commented Issue: IntrinsicMultiplyUint64 and IntrinsicMultiplyInt64 missing "inline" keyword [13029]

dcleblanc — Tue, 22 Mar 2011 18:24:12 GMT

VS 2010 gives a linker error:

Error 95 error LNK2005: "bool __cdecl IntrinsicMultiplyUint64(unsigned __int64 const &,unsigned __int64 const &,unsigned __int64 *)" (?IntrinsicMultiplyUint64@@YA_NAEB_K0PEA_K@Z) already defined in...

Adding "inline" to those function definitions resolves the errors.
Comments: ** Comment from web user: dcleblanc **

I'll get this fixed in 3.0.15 - thanks for reporting it.

Created Issue: IntrinsicMultiplyUint64 and IntrinsicMultiplyInt64 missing "inline" keyword [13029]

kgriffs — Wed, 16 Feb 2011 20:40:52 GMT

Commented Issue: bug gcc 4.3.2 and 4.4.1 int64_t [8791]

dcleblanc — Thu, 04 Feb 2010 06:10:24 GMT

This is now fixed by planned release 3.0.13p

Commented Issue: bug gcc 4.3.2 and 4.4.1 int64_t [8791]

dcleblanc — Wed, 13 Jan 2010 20:19:44 GMT

The RegMultiply stuff needs to be kept to internal calls - for example, on the x64 Microsoft compiler, we can get some gains by using intrinsics that just do 128-bit math, just like we check 32-bit math with 64-bit. So I think it is OK to use the __int64 on stuff that we know is purely internal. Once we have the proper template specialization, then I think we're OK to force things to the __int64 type.

Commented Issue: bug gcc 4.3.2 and 4.4.1 int64_t [8791]

bmb — Wed, 13 Jan 2010 14:36:01 GMT

That's what I did, though I didn't think to add a compile-time assert :) It took new template arguments to some of the Multiplication, Divison, Addition and Subtraction helpers to make it all work.

Additionally, LargeIntRegMultiply<> was tricky... think about:
template<> class LargeIntRegMultiply< unsigned __int64, unsigned __int64 >
You can't just change this to template<typename T, typename U>, the same way you can for the various Helpers, since those types are used to select which specialization you want. The way I worked around this was by
changing it to:
template<> class LargeIntRegMultiply< unsigned __int64, unsigned __int64 >
{
template < typename T, typename U >
static bool RegMultiply( const T& a, const U& b, T& ret ) throw() ...
}
So the class's template arguments identify the size of the arguments, but you can still call RegMultiply() with unsigned long arguments.

Another alternative would be to leave LargeIntRegMultiply as __int64-only, and convert from the true argument types inside MultiplicationHelper. Now that I think about it, this might be cleaner, maybe a little more invasive change though.

Commented Issue: bug gcc 4.3.2 and 4.4.1 int64_t [8791]

dcleblanc — Wed, 13 Jan 2010 04:21:18 GMT

Sorry I haven't responded more quickly. The normal use of SafeMultiply is to let the compiler sort out the types by itself, so it would be:

__int64 a, b, c;
a = x;
b = y;
SafeMultiply(a, b, c);

Your analysis is correct - all the internal functions take __int64 directly. I can't see the patch from this (Windows) system, so I'd need to look at the changes. On a Microsoft compiler, the only way to get a 64-bit int is either long long or __int64. I don't think I'd considered long int. With my compiler, I get this:

long int a, b, c;
a = 1;
b = 2;
SafeMultiply(a, b, c);

> MultiplicationHelper<long,long,1>::Multiply(const long & t=1, const long & u=2, long & ret=-858993460) Line 1576 C++

But then if I make them long long, I get:

> MultiplicationHelper<__int64,__int64,11>::Multiply(const __int64 & t=1, const __int64 & u=2, __int64 & ret=-3689348814741910324) Line 2606 C++

I have no idea what the standard says about these types, and whose compiler is right, at least with respect to long int vs. long long. I'm fully aware that a long can be any length according to the standard. I have to wonder if we can get away with just not specifying the first 2 template types - looks like the code would work properly either way. For example, we have:

template <> class MultiplicationHelper<__int64, __int64, MultiplicationState_Int64Int64 >

And there is exactly one that refers to MultiplicationState_Int64Int64, and I think we could just change it to:

template <typename T, typename U> class MultiplicationHelper<T, U, MultiplicationState_Int64Int64 >

It should still work, and we could add a compile assert that sizeof(T) == 8

Is that what you did?

Commented Issue: bug gcc 4.3.2 and 4.4.1 int64_t [8791]

bmb — Wed, 13 Jan 2010 00:43:15 GMT

Hi, I see this problem too. I think the issue stems from 64-bit GCC -- on my platform at least,
sizeof(long) == 8
sizeof(long long) == 8
To the type checker, those types aren't equivalent, even though they have the same size. But, the existing GCC code essentially assumes that long long (a.k.a __int64) is the only 64 bit type, so any Helper specialization that's 64-bit only takes __int64 directly instead of taking a type argument.

I took a stab at fixing this and have a (prototype) patch, it adds template arguments to several Helper definitions so that they can be generated for long and for long long. Also included in this patch are workarounds to eliminate GCC warnings (-Wall is clean for me on gcc 4.2.4). I've only compile-tested so far, and only on GCC.

Does something like this seem workable? If so, I'd be happy to clean it up and submit it. (and separate it into 2 parts if need be)

Thanks,
Brian Bloniarz

Created Issue: bug gcc 4.3.2 and 4.4.1 int64_t [8791]

stuav — Wed, 16 Sep 2009 11:11:58 GMT

Created Issue: Potential performance gain from non-member operator+

Niels_Dekker — Fri, 19 Jun 2009 23:03:19 GMT

Hi David,

I very much enjoyed your show at http://channel9.msdn.com, together with Ale Contenti, and I'm glad to hear that SafeInt is doing so well at Microsoft.

You have clearly put a lot of effort into the performance of SafeInt, but there may still be another opportunity. I got the impression from your presentation that users often deal with SafeInt objects that are created on the fly, as unnamed temporary objects ("rvalues"). For example, when i and j are built-in integers, a user might do:

result = SafeInt<int>(i) + j;

This will call your operator+ template member function:

template < typename U >
SafeInt< T, E > operator +( U rhs ) const

Now when the optimizer applies "copy elision", you might save a few machine instructions, by having operator+ as a non-member friend function instead:

template < typename U >
friend SafeInt< T, E > operator +(SafeInt< T, E > lhs, U rhs )
{
details::AdditionHelper< T, T, E >::Addition( lhs.m_int, rhs, lhs.m_int );
return lhs;
}

The C++ Standard allows the compiler to skip a copy-construction, when the unnamed temporary, SafeInt<int>(i), is passed "by value" to a function. And indeed, looking at the ASM code of a little SafeInt<int> test (generated by VC++ 2010 beta 1, release configuration), the "friend version" skips a few instructions, that the original version does:

lea eax, DWORD PTR $T5821[ebp]
mov DWORD PTR $T5821[ebp], edx

Honestly I haven't yet tested extensively, but it looks like there's some gain here...

HTH, Niels

Created Issue: Need to use standard defines for GCC, remove warnings from test rig

dcleblanc — Wed, 03 Dec 2008 18:51:57 GMT

Switch to #ifdef __GNUC__, suppress warnings from test rig, try seeing if we can raise warning level to -Wall.

Created Issue: SafeInt does not compile correctly on MacOS

dcleblanc — Wed, 03 Dec 2008 18:49:35 GMT

We're getting compiler errors out of anything where the return type is known and we accept SafeInt<T> op SafeInt<U>.

Commented Issue: Five changes to improve C++ Standard conformance

dcleblanc — Wed, 03 Dec 2008 18:42:59 GMT

Hi David!

I'm glad to see that SafeInt is back again! Actually I made a few changes to my local copy, in order to improve its conformance to the C++ Standard. Please consider merging them into the official version. I made the following changes:

* Removed template magic from IsFloat, because it's non-Standard (sorry).
Your version depends on __is_enum, which is a Microsoft compiler extension, and it uses ( (T)( (float)1.1 ) > (T)1 ) as if it's an "integral constant expression" (ICE), which is also non-standard at the moment...

* Replaced C_ASSERT(false) by C_ASSERT(sizeof(T) == 0), because C_ASSERT(false) might yield compile errors before template instantiation.
See also: Boost.StaticAssert, "Use in templates", by Steve Cleary and John Maddock
http://www.boost.org/doc/html/boost_staticassert.html#boost_staticassert.templates

* Removed (unsigned __int64) cast from tmp argument, to avoid passing an unnamed temporary object (rvalue) by reference to RegMultiply.
David, please double-check: (unsigned __int64)tmp might have been a bug! And if it isn't a bug, I might have introduced one!

* Added template keywords ("::template") to dependent member-names.
See also Comeau C++ Template FAQ, "What is the ->template, .template and ::template syntax about?"
http://www.comeaucomputing.com/techtalk/templates/#templateprefix

* Replaced _int64 by __int64, in Addition. (Mind the underscores!)
Just a typo, I assume!

The issues were found with help from g++-4 (GCC) 4.3.2, running on cygwin. But note: these issues are not GCC-specific! Hereby attached my modified version of 3.0.11p
Comments: ** Comment from web user: dcleblanc **

Thanks - that will allow us to raise the warning level. I also got Michael Howard to try compiling on a Mac, and it has all sorts of interesting errors - seems they're behind on the gcc version. Also nice to know what the right #ifdef to use for gcc - I'll correct that.

Commented Issue: Five changes to improve C++ Standard conformance

Niels_Dekker — Wed, 03 Dec 2008 16:44:23 GMT

GCC version 4.2 or higher allows warnings to be disabled by a pragma. For example, the following would disable "warning: unused variable 'fooBar'":

#ifdef __GNUC__
#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 1)
// GCC version 4.2 or higher:
#pragma GCC diagnostic ignored "-Wunused-variable"
#endif
#endif
See:
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

Unfortunately it doesn't seem to offer push/pop for warnings. It doesn't seem to disable the enum warning either ("-Wenum-compare"). But luckily you've worked around that one already.