Integer Overflow and operator::new

re: Integer Overflow and operator::new

Alexei Zakharov — Wed, 07 Dec 2005 13:08:03 GMT

Is there any rational reason to use plain arrays in today’s C++ code? Even if there wasn’t any possibility of integer overflow there are so many factors against C++ arrays (like type safety, exception safety to name a few) and so many proper abstraction classes developed to substitute arrays in C++ that there is no excuse to use plain vanilla C++ arrays in your code anymore. The simplest suitable general purpose substitute is std::vector. It’s been a part of the standard for 7 years. It’s just a shame not to know about it and not to advocate its use instead of arrays. It’s got neither problems listed above nor the integer overflow problem. The bottom line is you can enhance the compiler to protect you from the unsafe C++ constructs (C legacy really), but at the end of the day they are still inherently unsafe and dangerous and your code is still vulnerable. It’s just not the way to go with this language. Better, safer, higher level abstractions is the way to go. The language provides you with the tools you need to build them, and it also provides an excellent standard library that already has many abstractions you need.

re: Integer Overflow and operator::new

mTIE — Mon, 12 Dec 2005 21:43:47 GMT

So why not put an overflow check inside the implementation of new[]()??

I would argue that if new CFoo[(1<<31)+1] runs a pointer to an array of [1] allocated object, that's a bug in new, and should be fixed in the RTL.

re: Integer Overflow and operator::new

Peter — Wed, 28 Dec 2005 14:37:46 GMT

The mul instruction is the slowest way to multiply the number by 4. You can get the same result faster with LEA edx, [edx * 4] or with SHL edx, 2 or with ADD edx, edx / ADD edx, edx

What was optimization switches (/O1, /O2) when you compiled this code?

re: Integer Overflow and operator::new

Albatross — Thu, 05 Jan 2006 02:33:43 GMT

The new operation compiler "last chance" security protection is OK.

However, I think a clarification on the usage of the MAX_FOO_ALLOWED upper layer protection proposed is necessary.

The nature of the "integer overflow" scenario is because of the implicit sizeof multiplication that the new operator will execute, for such reason MAX_FOO_ALLOWED must be calculated based on that.

#define MAX_CPUREG_VALUE (2^CPUBITS)

#define MAX_FOO_ALLOWED
(MAX_CPUREG_VALUE / sizeof(CFoo))

re: Integer Overflow and operator::new

Albatross — Thu, 05 Jan 2006 02:34:24 GMT

Dean - Integer Overflows: The Next Big Thing

Dean - Integer Overflows: The Next Big Thing — Mon, 05 Jun 2006 14:03:53 GMT

PingBack from http://codeka.com/blogs/index.php/dean/2006/06/05/integer_overflows_the_next_big_thing

Why Windows Vista is unaffected by the VML Bug

Michael Howard's Web Log — Thu, 11 Jan 2007 06:47:52 GMT

MS07-004 does not affect Windows Vista, even though the coding bug is there. Why? The bug is an integer