SafeInt Discussions Rss Feed

New Post: SafeInt at Boost?

noloader — Sun, 25 Sep 2011 21:57:01 GMT

Timothy003 wrote:

Boost has really smart people in its community, and sets ultra-high standards. Libraries are peer-reviewed too, so you'd get a lot of good feedback on your code. For example, I grabbed the latest SafeInt3.hpp, opened it up, and immediately saw this:
#if !defined NULL
#define NULL ((void*)0)
#endif
// These two may not be defined, either
#if !defined uintptr_t
#define uintptr_t size_t
#endif

#if !defined intptr_t
#define intptr_t ptrdiff_t
#endif
// Might need this for gcc and older Microsoft compilers
#if !defined nullptr
#define nullptr NULL
#endif
Code like that is evil. The folks at Boost would surely let you know about it, and you'll learn modern C++ programming paradigms, improving the quality of your code.

# Boost has really smart people in its community, and sets ultra-high standards.
I'm not sure about the ultra high standards.

# Libraries are peer-reviewed too, so you'd get a lot of good feedback on your code
That Boost will accept anything and hope that someone will [eventually] spot an error is a detriment, not a feature. For example, it appears Boost accepted threads and rolled them out without rigorous review or acceptance testing. Distributions generally don't backport bug fixes, so downlevel users are stuck with defective code.

On my cursory review, Boost::Threads did not meet production quality (I filed about 15 bugs against it). For example, ignoring return values from WaitForSingleObject and pthread_mutex_lock was egregious. Its something I would expect from a self-taught K&R coder. I don't think a CompSci freshman would make the same mistakes. And I don't want code like that in my code base.

It also appears Boost does not audit the bug database. To date, none of the bugs have even been acknowledged.

# Code like that is evil.
Have a look at Boost::Test and its use of macros sometime...

New Post: SafeInt at Boost?

noloader — Sun, 25 Sep 2011 20:33:23 GMT

Timothy003 wrote:

noloader wrote:

Timothy003 wrote:

.... In most cases, the overhead will be negligible. Without solid profiling, I can't justify the security tradeoff. But if you have proof that the vector has too much overhead, then of course you shouldn't use it. Otherwise, it would be premature optimization.

Seriously? A program has to be correct before anything else.

Out of curiosity, how can you be certain the attacker does not control the input?

Are you implying that dcleblanc's code is safer and more correct? Other than relying on undefined behavior with the type punning, there's already a bug in it; it doesn't validate the packet's size. With vector, iterator debugging will give you a better chance of catching incorrect code.

The two examples don't do the same things, anyway.

# Are you implying that dcleblanc's code is safer and more correct?
Yes, I believe LeBlanc's SafeInt code is safer in general.

If the time ever comes, I believe ignoring wrap and overflow will be grossly negligent. The industry enjoys software patents, it should also enjoy liability.

# Other than relying on undefined behavior with the type punning...
My bad, I was commenting in general, not in the particular examples.

For what its worth, the Visual Studio compiler is more tolerant of punning. I think VS just does the right thing and gets the alignments right (with no warning).

# With vector, iterator debugging will give you a better chance of catching incorrect code.
I love debug builds and asserts (I'm a student of John Robbins), but this is a problem in practice. To convince yourself, install libboost via apt-get or yum and define _GLIBCXX_DEBUG (http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html). I recently [incorreclty] filed a report against Boost::Regex (it was an ABI problem).

I know I could have built the source from scratch. But Boost has broken the tried and true configure/make/install in favor of something else buried in a spaghetti of documentation. I could be wrong, but I had no joy in building on Solaris (a Boost bug report was filed, no acknowledgement to date).

Jeff

New Post: SafeInt at Boost?

Timothy003 — Sat, 24 Sep 2011 20:44:51 GMT

noloader wrote:

Timothy003 wrote:

.... In most cases, the overhead will be negligible. Without solid profiling, I can't justify the security tradeoff. But if you have proof that the vector has too much overhead, then of course you shouldn't use it. Otherwise, it would be premature optimization.

Seriously? A program has to be correct before anything else.

Out of curiosity, how can you be certain the attacker does not control the input?

Are you implying that dcleblanc's code is safer and more correct? Other than relying on undefined behavior with the type punning, there's already a bug in it; it doesn't validate the packet's size. With vector, iterator debugging will give you a better chance of catching incorrect code.

The two examples don't do the same things, anyway.

New Post: SafeInt at Boost?

noloader — Sat, 24 Sep 2011 20:28:56 GMT

Timothy003 wrote:

.... In most cases, the overhead will be negligible. Without solid profiling, I can't justify the security tradeoff. But if you have proof that the vector has too much overhead, then of course you shouldn't use it. Otherwise, it would be premature optimization.

Seriously? A program has to be correct before anything else.

Out of curiosity, how can you be certain the attacker does not control the input?

New Post: SafeInt at Boost?

Timothy003 — Thu, 11 Aug 2011 02:45:43 GMT

It really depends on the requirements of the application. In most cases, the overhead will be negligible. Without solid profiling, I can't justify the security tradeoff. But if you have proof that the vector has too much overhead, then of course you shouldn't use it. Otherwise, it would be premature optimization.

There's a way to get the fixed-width types without the header by using limits.h instead, but practically only Boost needs that kind of portability.

New Post: SafeInt at Boost?

dcleblanc — Thu, 11 Aug 2011 01:09:17 GMT

Heh - here's how you really do it:

unsigned long GetHeaderLen(const char* pPacket, unsigned long cbPacket)
{
   ip* pIp = reinterpret_cast<ip*>(pPacket);
   if( pIp == NULL || pIp->ip_v != 4) return 0;
   unsigned long len = pIp->ip_hl * 8; // int overflow not possible, ip_hl can be at most 15 - only 4 bits
   return len > cbPacket || len < 20 ? 0 : len;
}

Lots easier and no overhead. You _can_ do nearly anything using STL, the question is whether maybe plain old C might be a more efficient choice (and sometimes more readable)

Usually Visual Studio fixes up line endings - have to look into that.

The point about the header is why I try as much as possible to avoid depending on them (for this sort of project). Given some number of compilers that are supported on some number of platforms, the more headers, the more chance for headaches.

New Post: SafeInt at Boost?

Timothy003 — Wed, 10 Aug 2011 22:27:38 GMT

This should work:

void handle_packet(vector<char> packet)
{
    // determine length of IP header
    uint32_t word_1;
    packet.at(4 - 1);
    memcpy(&word_1, &packet[0], 4);
    word_1 = ntohl(word_1);
    auto length = 4 * (SafeInt<uint32_t>(word_1) << 24 >> 24 >> 4);
    if (length < 20)
        throw some_error();
    packet.at(length - 1);
    // get iterator to data section
    auto data = packet.begin() + length;
    if (data != packet.end())
    {
        // do stuff with data
    }
}

The only reason to use operator new[] that I can think of is optimization, though vector is so fast in VC10 that I can't see it happening much. I would store variable-length structs using malloc. operator new[] seems inappropriate if I'm circumventing the type system anyway.

I know it sucks giving up nullptr. I love it myself. NULL was a mistake to me. But I've tried shoehorning nullptr into my program when GCC didn't have it, and it wasn't easy. std::function needed an overload for nullptr_t, for example.

stdint.h isn't available in VC9. I wanted to see if you would add typedefs for an extra layer of portability, like:

// assume we have <stdint.h> by default
#define SAFEINT_HAS_STDINT_H
// MSVC versions earlier than 10.0
#if defined _MSC_VER && _MSC_VER < 1600
#undef SAFEINT_HAS_STDINT_H
#endif  // defined _MSC_VER && _MSC_VER < 1600

#ifdef SAFEINT_HAS_STDINT_H
#include <stdint.h>
#endif  // SAFEINT_HAS_STDINT_H

namespace safeint
{
#ifdef SAFEINT_HAS_STDINT_H
    using ::int8_t;
    using ::uint8_t;
#elif defined _MSC_VER
    typedef __int8 int8_t;
    typedef unsigned __int8 uint8_t;
#else   // defined _MSC_VER
#error need fixed-width integer types
#endif  // defined _MSC_VER

    template<class Ty>
    class safeint
    {
    public:
        operator int8_t() const;

        operator uint8_t() const;
    }
}

That's how I would do it.

By the way, the line endings are inconsistent in 3.0.16.

New Post: SafeInt at Boost?

dcleblanc — Wed, 10 Aug 2011 17:35:31 GMT

I don't have time to pull up the headers to show a concrete example, but an IP header is a variable-length structure that has a minimum of 20 bytes. So you have to calculate the offset to the TCP header, and you end up using pointer math to do so. I could allocate the bytes using a vector, but the only gain I'd get out of it would be to have it clean itself up, and I'd take a hit of some overhead in what's typically highly perf-sensitive code. If I can't realistically use iterators, then converting the vector to a raw pointer really doesn't gain me much in terms of safety.

Another example that I'd really rather not attempt to use a vector with would be a security descriptor on Windows - variable-length structs followed by more variable length structs. You will run into the same issues with most images, especially WMF or EMF, and to some extent bitmaps. So Stephan's point was that one should _never_ call new[] - mine is that it should be called as infrequently as possible.

I know a fair bit about macros, though what did escape me and led to this mistake was that you can't check for a keyword with a #if defined. I should have tested exactly that piece of code. I've stepped through literally every single line and return case in the rest of the class, but defines and such are somewhat more annoying to debug.

You're right that many programmers have a very fragmented knowlege - ran into a guy once that didn't know how to use sprintf, and went though hideously complex C++ hoops to do the same thing. You're also right that there's an amazing variance of errors and brilliance out there - I work on Office, which is over 100 million LOC, and I think every programming approach can be found in there somewhere - partially due to the fact that some of it is 20-25 years old.

I'm sorely tempted to go back to NULL. That's what I get for attempting to use new features. I only actually need it in one function. Other instances of NULL occur in some of the pointer overloads.

No, I wasn't planning on it being used on other compilers at the time I started. If I were to do it over, I'd probably use the types set up in stdint.h.

To be honest, this code has been reviewed by a large number of experts. Some find interesting issues, others don't. The most effective thing that we've done is to create a rigorous test harness. It's one thing to look at code and think it looks good, quite another to _prove_ it works - we caught errors created by the Intel compiler this way, and then proved that we'd coded around them. Most of what's left are things like you caught, where there's no runtime effect, just playing nice with other libraries and code. The remainder of what's left is debatable issues, like how much of the guts to enclose in a namespace, one file or two, whether to put the whole class's external interfaces in a namespace, etc.

I should still look into getting it into Boost, though I think the legal stuff is the bigger hurdle. We have a perfectly fine license, they do too, not sure why everyone can't just get along... It would be one thing is one license were restrictive, but neither of these are.

New Post: SafeInt at Boost?

Timothy003 — Tue, 09 Aug 2011 20:51:23 GMT

I believe GCC adheres to the standard with NULL, so it's not exactly treated the same as nullptr. It just generates warnings where nullptr would generate errors.

I often favor the theoretically correct myself. I'm not sure why using a std::vector for safety checks would be a theoretical argument, though; the standard doesn't mandate the safety checks. It seems more of a practical one, since theoretically our code is error-free while practically our code has buffer overflows and the std::vector catches them. Can I have an example where a std::vector can't easily replace operator new[]?

I agree that macros are a necessary part of the language. It's just that many programmers still use macros inappropriately. I couldn't assume you knew about them. Programmers have surprisingly fragmented knowledge of C++, so someone who knows how to write template specializations but doesn't know how the preprocessor works doesn't sound far-fetched to me. Just look at the code of various open-source libraries other than Boost.

I don't understand why you need to define nullptr. Can't you use NULL in your code instead? Remember, nullptr isn't the same as NULL. And you'll be making the user deal with errors when their compiler doesn't support it.

I know the __int8 and __int16 stuff would be difficult to remove. I guess you weren't planning on this library outgrowing MSVC when you started it. If you could do it again today, you'd use typedefs, right?

I'm not as worried about the namespaces as I am with the macros. But, of course, other issues take priority over both of those. Identifier conflicts would probably cause compile errors anyway. If nobody's complained yet, then your macros have good chances of uniqueness.

I'd submit issue reports like you prefer, but unfortunately my time is extremely limited. Having your code reviewed by experts is mainly what I'm going for. Boost developers can find and discuss bugs with you just like I have. Even if your library doesn't make it into Boost, the review process would be a nice way to improve it.

New Post: SafeInt at Boost?

dcleblanc — Tue, 09 Aug 2011 17:37:40 GMT

That's an interesting issue with the NULL declaration - oops - my bad. I was surprised that my gcc environment didn't have it defined, and then I got the two forms of the definition flipped.

Stephan and I have gotten into some debates, largely because he works only on a library, where I write features, and work on a wide array of code - some is high level C++, some is C written like you might have seen 20 years ago. He tends more towards what's theoretically correct, and I tend more toward the practical. For example, it is his position that we should never allocate an array of bytes, but always use a std::vector. He's right that the vector is safer, but go try to take apart a TCP/IP header using a vector - wouldn't be fun. Might be possible, but I'm not sure whether anyone coming after could figure out what it was doing. That said, I do use std::vector for many cases where I need an allocated array - an iterator (at least a current implementation) and the [] operator will crash rather than create an exploit. It's also a matter of absolutes - it isn't that we should _never_ call new[], it is that we should prefer std::vector.

Same sort of thing with macros - there are things you can only do with macros. I don't like them, try not to use them, and often rip them out and turn them into inline functions, but they're not evil - just a dangerous tool (just like the rest of the language).

The issues you pointed out were good ones - changes made as a result:

NULL (if needed) is defined as 0
nullptr is only defined if you define NEEDS_NULLPTR_DEFINED 1
intptr_t define is removed
uintptr_t instances changed to size_t, define is removed

An intentional design decision was to reduce the number of headers required by this class to the least possible. A side-effect is that depending on the environment, you don't always see everything defined that you expect.

Issues I'm not going to address at the moment -

The __int8, __int16, etc, are artifacts because the library was originally written for Visual Studio, and I can use them there without including any headers. They're nicely descriptive, which is handy in a world where 'long' has different meanings on different compilers and architectures. So that might be a technical violation of the language, but you can blame the Visual Studio team - I'm just following them. I could go rename them all, but it would make getting a diff between versions a major pain. So that's a won't fix.

Greater use of namespaces - there's different valid arguments here. Some of the guts of the class work nicely as standalone utilities, especially IntTraits (yes, I know Boost has an analogue). Wrapping these in a namespace would be inconvenient. However, we made the opposite decision with the Visual Studio version. Using a namespace for the overall class seems inappropriate unless it is part of a larger library - again, the Visual Studio version does get wrapped in a namespace, along with a number of other utilities. I'd consider putting more of the implementation into a namespace, but it seems less important than say getting the throw decorations correct.

Thanks for the input, and there's no offense taken.

New Post: SafeInt at Boost?

Timothy003 — Tue, 09 Aug 2011 03:31:19 GMT

I'm sorry, I made a mistake in that example. I meant char *p = NULL;. Can't believe I missed that after proofreading it dozens of times. :-(

I'm sorry if I came off harsh. That was certainly not my intent. I used the word 'evil' because Stephan uses it to describe such things, and I put a lot of effort into the examples because I saw some questionable code and wanted to show you exactly my sentiments. I respect you and your work. Please don't take it personally. I'll shorten my explanations from now on.

Congratulations on keeping this project going for so long! I saw your demo of SafeInt on Channel 9 and came here to check out the library. I'm very grateful that there's such a mature checked-integer library available for free.

New Post: SafeInt at Boost?

dcleblanc — Tue, 09 Aug 2011 02:55:38 GMT

OK, well, first of all, you can't do:

char* c = malloc(1);

to start with - it emits this:

zz.cpp(5) : error C2440: 'initializing' : cannot convert from 'void *' to 'char*'
Conversion from 'void*' to pointer to non-'void' requires an explicit cast

That's completely independent of whether someone has defined NULL.

Next, gcc is doing something a little non-standard, by treating NULL the same as nullptr, which is why nullptr exists. That's fine, and the expectation is that the user has almost certainly already defined NULL, so anything I do in this class won't matter. You see the same definition all over many other headers. Note that I don't bother to make it conditional on C++, since this class obviously isn't compiling on a C file.

Next, as it turns out, I don't need intptr_t, and the instances of uintptr_t can be replaced with size_t. Regardless, uintptr_t and size_t, and the corresponding signed values are guaranteed to have the same size and behavior. Replacing one for the other won't cause any harm, even if it is regrettable. I am well aware of the evils of macros, and have largely tried to avoid them any time possible. I'm also well aware of how to use namespaces, and you may note that these are used internally to the class. At the moment, this version of the class isn't part of an external set of libraries, and thus it would be inappropriate (and clumsy) to add namespaces. There are namespaces defined in the Visual Studio version, which I also maintain.

I also don't think I've named anything with __, except to follow what Visual Studio has done with __int8, __int16, etc. While that may not be something you're happy with, I can count on these being present in my primary target compiler. That one is a "won't fix".

Yes, I do know Stephan. He's certainly a very smart guy, though I did report some integer-related bugs in his STL allocator code.

While we're giving tips, you're more than welcome to report bugs. I'll certainly fix the uintptr_t and intptr_t issues - it was a surprise that my Linux system wouldn't compile when these types were used, and you're right that the defines aren't working as expected. However, please do not use words like 'evil', and it is especially silly to lecture me on modern C++ techniques when you're looking at a class that uses partial template specialization extensively. I'm clearly acquainted with modern programming techniques.

Here's what I would have preferred to see:

Issue - uintptr_t and intptr_t shouldn't be defined. intptr_t isn't used, and size_t would work just as well where uintptr_t is used.

You're also looking at nearly 7000 LOC that have evolved over the last 8 years. It would be a miracle if everything were perfect.

New Post: SafeInt at Boost?

Timothy003 — Tue, 09 Aug 2011 00:26:44 GMT

Thanks for listening! Of course, I'll explain.

The standard library is a special kind of library. It's allowed to declare identifiers that are reserved. This includes:

Names in the global scope that begin with an underscore
Names anywhere that contain two consecutive underscores
Names anywhere that begin with an underscore and a capital letter

That's why you see a lot of underscore usage in standard library headers. This makes sure that the library's internal identifiers don't clash with everyone else's. For this to work, though, everyone else must also not declare reserved identifiers. So the standard libraries get to use names like __foo, _Foo, and foo__, while everything else gets to use names like foo, Foo, and foo_.

Where does that place non-standard libraries? The Boost convention is to use namespaces. Just as the standard library puts everything into namespace std, Boost puts everything under namespace boost. Macros ignore namespaces, so Boost capitalizes all macros and prefixes them with the name of the library (e.g. BOOST_UNREACHABLE_RETURN). The rationale for that is the same as for namespaces, which I'll get to in a minute.

In the first piece of code, you define NULL as ((void*)0). There are two problems with this.

The user now cannot write char *p = malloc(n); because void * is not implicitly convertible to char *.
GCC has a special definition for NULL that allows the implicit conversion but gives a warning whenever one tries to convert it to a non-pointer type.

A conforming standard library implementation will define NULL when the header <cstddef> is included. It's required by ISO C++. Every sane implementation has it.

In the second example, you check for and define intptr_t and uintptr_t. This is flawed because those two names are typedefs according to the language. You can't check for them using the preprocessor. Also, consider what could happen when GCC does define the names. Your header would change the meaning of intptr_t and uintptr_t. If you're lucky, the two definitions will agree; <cstdint> would say typedef ptrdiff_t intptr_t; typedef size_t uintptr_t;. However, if the library uses some other types, bad things could happen. Code that uses intptr_t and uintptr_t would then change simply because they included your header.

Macros are generally avoided in modern C++. They replace all occurrences of the name regardless of where they are. For example, the following code...

namespace boots
{
	typedef std::intptr_t intptr_t;
}

...will be preprocessed into...

namespace boots
{
	typedef std::ptrdiff_t ptrdiff_t;
}

It's like doing a find-and-replace-all in your code, the standard library's code, and everyone else's code. Macros are evil. If there's no way to do what you want without macros, then use them, but follow the naming convention so that users won't unknowingly have their code changed. Likewise, don't declare identifiers that are in all capital letters that aren't prefixed by your library name, so that the user's macros won't change your code.

In the last piece of code, you check for and define nullptr. nullptr is not a macro. It's a keyword, and, like typedefs, you can't check for keywords during preprocessing.

Generally, if a feature isn't available in a particular C++ implementation that you need to support, don't use it. In place of nullptr, you can use NULL. If there's no replacement, like with intptr_t, then use your own definitions, but put them in your own namespace (or prefix their names if they're macros). Namespaces prevent conflicts with user code and other libraries. You shouldn't define anything outside of your namespace unless you're absolutely certain that the definition is, and will be, unique. Remember: In any translation unit, a template, type, function, or object can have no more than one definition. Imagine every library defining the std::vector!

To reiterate,

Standard libraries use names like __foo, _Foo, foo__, and _FOO.
Non-standard libraries use names like boots::foo, boots::Foo, boots::foo_, and BOOTS_FOO.
Users use names like foo, Foo, foo_, and FOO.

Thanks for taking the time to read this. I'm a passionate C++ programmer who loves using libraries to ease my work. But it's frustrating to see libraries trample over each other. And it's impossible for me to review all the library code by myself. You might know Stephan T. Lavavej--he's a developer of the Visual C++ standard library implementation. He's really good with words. Maybe he could give you some tips.

New Post: SafeInt at Boost?

dcleblanc — Mon, 08 Aug 2011 17:22:03 GMT

Could you perhaps explain how these are evil?

If this is really wrong, then there's a number of standard libraries that have bugs. There's 10 different headers in the Microsoft headers that have NULL defined, which is needed because it isn't defined as part of the language. A compiler and platform-independent library such as this one has to define anything that isn't part of the language standard, or it has to include standard headers that will.

Then uintptr_t and intptr_t are part of the language, but some versions of gcc that are supported by this class don't seem to know that these are keywords, and want them defined. If you have them defined, then these conditional definitions don't matter. Finally, nullptr is part of the newest edition of the standard, and this class is still supported on a number of compilers that are several years old, and you need that either defined as a keyword, or it needs a #define.

Thanks for your interest, and I'm happy to know that Boost could teach me more about modern C++ programming.

New Post: SafeInt at Boost?

Timothy003 — Mon, 08 Aug 2011 08:41:01 GMT

Boost has really smart people in its community, and sets ultra-high standards. Libraries are peer-reviewed too, so you'd get a lot of good feedback on your code. For example, I grabbed the latest SafeInt3.hpp, opened it up, and immediately saw this:

#if !defined NULL
#define NULL ((void*)0)
#endif

// These two may not be defined, either
#if !defined uintptr_t
#define uintptr_t size_t
#endif

#if !defined intptr_t
#define intptr_t ptrdiff_t
#endif

// Might need this for gcc and older Microsoft compilers
#if !defined nullptr
#define nullptr NULL
#endif

Code like that is evil. The folks at Boost would surely let you know about it, and you'll learn modern C++ programming paradigms, improving the quality of your code.

I hope you can get the legal stuff out of the way. Good luck!

New Post: SafeInt at Boost?

dcleblanc — Tue, 29 Mar 2011 22:31:18 GMT

Thanks for reminding me - I think you could probably get an exception for this one, as you're almost certainly allowed to use libraries from Visual Studio, and this version is very, very close to the same thing as in Visual Studio. I do need to go have the discussion with legal people to see how this could work.

My focus just this moment is to get 3.0.16 up - I'm trying to get the warnings down, and get it to work right with the older compiler Apple likes to use.

New Post: SafeInt at Boost?

petke — Tue, 29 Mar 2011 21:27:34 GMT

I just would like to say that having SafeInt in boost would be very much appreciated. The C++ community would be grateful.

Many a companies have defacto rules like "no 3rd party libraries allowed except boost". People trust the boost libraries just because the name is so well known and respected, even if they are a bit buggy sometimes.

Also it would be good PR for MS.

Just my 2 cents.

New Post: Why no assembly?

dcleblanc — Tue, 15 Jun 2010 17:08:03 GMT

The problem is two-fold. First, the overflow flag doesn't get set for everything. For example, assigning a 32-bit int to a 16-bit int is dangerous, but the CPU doesn't see an overflow. Adding two 16-bit ints won't set the overflow flag, either. There's a bunch of cases that don't set the overflow flag. I haven't checked, but I suspect that you could well run into the same thing on a 64-bit CPU where a 32-bit multiplication doesn't set the overflow flag, though it might because of different assembly instructions.

The second part of the problem is that as soon as you start using assembly, the compiler decides that you must know what you're doing and disables optimizations. Michael Howard and I tried a test case with multiplication, and the inline assembly came in as _much_ slower than optimized SafeInt.

We've recently been dinking with what produces the best assembly for a test case like uint32 * uint32, and it is all around upcasting to 64-bit, and then you get some very different numbers of branches depending on how you detect an overflow. If you _really_ want to get hard core about perf, what I'd suggest would be to take the approach I use in SafeInt for the specific operation you want, and then manipulate the logic until the optimizer gives you something you like.

New Post: Why no assembly?

dddejan — Tue, 15 Jun 2010 08:02:38 GMT

Also, after some hacking, I got an equivalent in gcc

#include <iostream>
#include <limits> 

using namespace std;

int main(int argc, char* argv[])
{    
    int x, y;
    bool overflow = false;
    x = numeric_limits<int>::max();
    y = x + 1;
    asm("jno no_overflow\n"
	"mov\t$1, %0\n"
        "no_overflow:\n"
       :"=r"(overflow)
       :"r"(overflow) 
       );
    if (overflow) cout << "overflow" << endl;
    else cout << "no overflow" << endl;
    return 0;
}

Cheers, Dejan

New Post: Why no assembly?

dddejan — Tue, 15 Jun 2010 00:40:30 GMT

I recently encountered the need to check for int overflows in order to speed up the computation in an application we are developing that involves big numbers. We basically use the same trick with extending the size of the operands and checking if the result fits. It is unusual to have to do this when the processors do offer overflow flags and we can access them (although not in a nice way). Since you definitely have more experience in developing with overflows, I was wondering why you are not doing something like this

#include <iostream>
#include <limits>

using namespace std;

#undef max

#define CHECK_OVERFLOW(code, label) \
code; \
_asm { jo label } \

int main(int argc, char* argv[])
{
   int x, y = 0;
   x = numeric_limits<int>::max();
   CHECK_OVERFLOW(y = x + 1, overflow_label);
   CHECK_OVERFLOW(x = y + 1, overflow_label);
   cout << "no overflow" << endl;
   return 0;
overflow_label:
   cout << "overflow" << endl;
}

Are there conditions where this would fail (like compiler optimizations), or is there other reasons that I'm not seeing?