{"id":34602,"date":"2022-01-03T14:38:55","date_gmt":"2022-01-03T19:38:55","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=34602"},"modified":"2022-01-03T14:38:55","modified_gmt":"2022-01-03T19:38:55","slug":"almost-always-unsigned","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/01\/03\/almost-always-unsigned\/","title":{"rendered":"Almost Always Unsigned"},"content":{"rendered":"

Dale Weiler<\/a> (via Richard Geldreich<\/a>):<\/p>\n

\n

There are a lot of arguments against the use of unsigned integers. Let me explain why I think they’re mostly incorrect.<\/p>\n

[…]<\/p>\n

Trap representations are actually quite insufficient as they can only trigger at runtime when those paths are successfully executed with the correct trap-producing inputs. This coverage is impossible to expect in any non-trivial program even with exhaustive unit testing. The idea is also incompatible in many contexts such as library code where you almost never want the library to panic, but rather all errors be recoverable by the calling application code, or in service-availability sensitive code which must not be susceptible to denial of service attacks, where a panic is pretty much not acceptable.<\/p>\n

[…]<\/p>\n

The reality is that the use of signed and unsigned paints all your integers red\nor blue, respectively. \n What color is Your Function<\/a>. The more of one you use, the more likely it is\neverything will also share the same signedness regardless of if it’s appropriate.\nSince most integers never require representing negative values, I personally\nthink it’s more appropriate to paint everything blue in this case.<\/p>\n

[…]<\/p>\n

In many ways signed integers are the null pointers of integers.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n