Actually, I find you should always use signed ints.

With signed ints, you can notice that '2-3' has below 0, and act accordingly. If you do '2-3' with unsigned ints, there is not really any way of finding out something went wrong (other than looking for very large numbers).

Of course, particularly in a financal system, you should probably use an integer type which throws/aborts if an out-of-bounds error occurs.

And this is why I almost always never trust advice that has the words 'always' and 'never'.

Or trapping overflow/underflow.

How about using programming language/number library that properly handles integer promotion or signals a condition when a number gets out of bounds. Obviously it's slower than unchecked processor integers, but as this story shows, in some circumstances it's well worth it.

Just validation of the input string would suffice. No need to use unsigned ints or promoted numerals.

Well, that's a start, but any subsequent math would involve numbers not directly entered by the user, so it's not sufficient by itself.

No. Either the value started as a signed value, and then was converted to an unsigned ( something well warned about by observing compile warnings or Lint ), or it was unsigned all along. Either way the same result would have occurred.

Slightly better is 64bit signed. There can always be overflow though. The reason these values are POD's is because tickers move around at a very high speed.

That's quite a controversial statement. Using unsigned ints may just clutter code without providing any safety. The value of 4e9 is still invalid, even though it's positive. As you say, checking your inputs is important, and in this case values can be too large, and should be rejected.

For instance: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...

Using "unsigned ints" for values that will never be negative allows you to perform one validation test instead of two. Use a typedef to avoid writing "unsigned" everywhere and you end up with less clutter in the code (for humans) and in the binary (for machines).

nanex

You should check before the operation that can produce result outside the valid range anyway.

Wrong example:

    unsigned int z = x - y;
    if (z > BIG_NUMBER) {
        return false;
    }

Good example:

    if (y > x) {
        return false;
    }
    unsigned int z = x - y;

The issue is

4e9 is invalid but in the middle of the way (more often than not) this may be interpreted as a negative number.

Hence you need to check for value 'bigger than allowed' and 'smaller than allowed'

For unsigned ints, there is a natural smallest value allowed: zero.

You're free to not follow my advice though.

And the google style guide is subtle, it's not what you're implying. You can't use 'short' for example unless explicitly.

However this was an unsigned int, otherwise it would show up as -6 (as int32 is −(2^31) to 2^31-1), the problem here is just validating the input.

Before we jump into how the code might have been wrong, there are other issues that can impact mission-critical applications like this that have little to do with the high-level code. In financial applications it's somewhat common to build the hardware to tolerate SEUs. For example, I know of one application where two identical digital subsystems are used, given the exact same input, and the outputs are compared. If the outputs ever differ a logic error is assumed and operation halted.

Logic errors are rare but not that rare. At sea level you can expect ~1 bit flip in 4GB of memory every 24 hours. Often it's in an invalid line or gets overwritten anyway, but for applications like this where one logic error can cost you your shirt, application of hardware-level error checking (ECC, SEU detection and correction, etc).

No, that's why you should always check your input data. It's a bug elsewhere, not a question of unsigned versus signed.

Using an unsigned int is what caused the problem...