Is one's complement a real-world issue, or just a historical one?

Question

Another question asked about determining odd/evenness in C, and the idiomatic (x & 1) approach was correctly flagged as broken for one\'s complement-based systems, which

Answer 1

We got off our last 1960's Honeyboxen sometime last year, which made it our oldest machine on site. It was two's complement. This isn't to say knowing or being aware of one's complement is a bad thing. Just, You will probably never run into one's complement issues today, no matter how much computer archeology they have you do at work.

The issues you are more likely to run into on the integer side are endian issues (I'm looking at you PDP). Also, you'll run into more "real world" (i.e. today) issues with floating point formats than you will integer formats.

Answer 2

RFC 791 p.14 defines the IP header checksum as:

The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.

So one's complement is still heavily used in the real world, in every single IP packet that is sent. :)

Answer 3

I decided to find one. The Unisys ClearPath systems have an ANSI C compiler (yes they call it "American National Standard C" for which even the PDF documentation was last updated in 2013. The documentation is available online;

There the signed types are all using one's complement representation, with the following properties:

Type                 | Bits | Range
---------------------+------+-----------------
signed char          |   9  |  -2⁸+1 ...  2⁸-1
signed short         |  18  | -2¹⁷+1 ... 2¹⁷-1
signed int           |  36  | -2³⁵+1 ... 2³⁵-1
signed long int      |  36  | -2³⁵+1 ... 2³⁵-1
signed long long int |  72  | -2⁷¹+1 ... 2⁷¹-1

Remarkably, it also by default supports non-conforming unsigned int and unsigned long, which range from 0 ... 2³⁶ - 2, but can be changed to 0 ... 2³⁶ - 1 with a pragma.