Hacker News Reader

Comment by eliteraspberrie | Hacker News Reader

I strongly disagree with the rationale for not supporting unsigned integer types by default. In fact, I think unsigned should be the default, and the advice on the Escher Technologies blog is harmful.

Other than that, Nimrod has been a pleasure to use. If you need a metaprogramming language to generate C, use Nimrod.

View on HN

I'll assert that a majority of C programmers do not understand unsigned types and misuse them.

It's quite common to end up needing to use both signed and unsigned types in the same expression and to end up invoking undefined behaviour trying to protect yourself. C overflow semantics (i.e. undefined) in particular.

Signed types should be the default, and overflow should be defined as wrapping two's complement. There's very good reasons why C# and Java chose these defaults.

The places where unsigned numbers are justified are incredibly rare: bitwise operations, and working with >2GB heap sizes on 32-bit machines. That's about it. In almost every other circumstance, using a signed type (the next size up if the range is inadequate) is better.

Especially pernicious is using something like size_t for things like container entry counts. It's very common to add and subtract with container counts, and very easy to end up inadvertently wrapping or mixing with signed types in common container algorithms.

PS: my experience was deeply coloured while working on the Delphi RTL, making it overflow safe. It was not trivial.

PPS: it was revealing that the comments on the article arguing in favour of unsigned types repeatedly made programming errors and invoked undefined behaviour. That's because unsigned types are misunderstood and misused.

I don't find bitwise operations incredibly rare. I use them fairly often in my side projects (various simulations and optimizers).

> The places where unsigned numbers are justified are incredibly rare: bitwise operations

I take it you do not work with bare metal at all.

I take you aren't aware OP was on the Delphi compiler team and has lot of experience with low level coding.

The point is that, "bare metal" is really a special case of programming.

Most general purpose programming languages don't have features specific for web-programming imported by default.

Nimrod supports bare metal programming just as fine as C. You just have to import the relevant modules, just as you'd import the URL module if you were writing a web-server.

Nimrod aims at being approachable to some of the Python/Ruby crowd as well, who are used to numbers that are always signed and can't overflow. Defaulting to the biggest available signed integers, and discouraging library writers from throwing unsigned integers at you for no reason is a decent compromise.

Third case, dealing with raw data from networks, from devices, from flash memory etc. where you actually need to manipulate every bit accurately.

Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative.

Overflow is a separate issue and you must either make sure you either know the range of the data and pick an appropriately sized storage type, or explicitly check for overflows.

> Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative.

This is actually where you have to be really careful, because there can be corner cases surrounding zero. E.g.:

  for (i=len-1; i>=0; i--) { ... }

Yes, either ints or unsigned numbers can overflow, but underflowing a natural number is much more common.

Don't take my word for it, ask Bjarne Stroustrup or Chandler Carruth: http://stackoverflow.com/questions/18795453/why-prefer-signe...

In that loop one should check that len is at least 1 first...

I read that page, or at least some of it, it mostly seemed to be opinion rather than solid reason.

> In that loop one should check that len is at least 1 first...

No. The code is correct in that regard if you use int for i and len. Having to check len is an artifact of using unsigned.

> I read that page, or at least some of it, it mostly seemed to be opinion rather than solid reason.

I'm not talking about the comments. I'm talking about what Bjarne Stroustrup (the designer of C++) and Chandler Carruth (Google's LLVM lead) are saying in the video (and which is summarized in the top comment).

Only if a sub 1 len is valid input, which it may not be. Either way the example is contrived and does not cover all other situations in which a scalar quantity is required. Not all are loop controllers.

I did not watch the video, no time right now. The top comment tells us what they think, not why.

I think this demonstrates a problem with C-style for loops (as opposed to iterators) more than unsigned integers.

It seems unreasonable to me that you need to write out the iteration variable 3 times in a C for-loop; I had a bug a couple weeks ago that took me longer to figure out than I care to admit. I wrote `for (int j = 0; i < N; ++j)`.

The problem lies with len-1 underflowing, not the loop that uses the result. For another example, to test congruence of x and y modulo m, you check if (x-y) % m == 0. This also blows up for unsigned integers if y > x unless m is a power of 2.

Even iteration is not always over containers or some other structure in a way where the boundaries can be inferred and do not have to be computed, and not always in an order that is implemented by an iterator (for example, some in-place sorting algorithms).

Even iteration over explicit ranges of unsigned integers can be handled by a Python range()-style iterator, without the risk of this bug (since the iterator itself is responsible for avoiding this gotcha).

Only if the language has ONLY iterators that are of the [closed, open) kind of interval. If you have, e.g., Smalltalk/Scala-like to:/to iterators (even if you have also iterators that exclude the upper end), you get the same problem in conjunction with unsigned integers (except that these languages use signed integers, so the problem doesn't show up).

It's a problem with C for loops. There is really no good way to write a counting down loop using a for loop. The fundamental problem is that a for loop is: test a condition, run a loop body, then run a step function. This is suited to counting up loops but when counting down what you want is: test a condition, run a step function, then run a loop body. If you use while loops instead of for loops, you will see the two loops are symmetrical and there is no underflow for unsigned types. See http://ideone.com/1ABiCw

I don't like C for loops, either, but this can happen with other types of for loops, either. E.g. in Pascal:

  for i := 0 to len-1 do begin ... end

This is counting up, not counting down, and len-1 is still going to be either 2^k-1 or result in an error when you're using unsigned integers.

While loops also don't fix it (not to mention that they have their own problem, such as forgetting or misplacing the iteration step). The primary issue is that len-1 is underflowing. Yes, you can avoid calculating len-1, but by that token, no error is ever a problem, because they can all be avoided with enough diligence and foresight. In that universe, Heartbleed never happened and the Ariane 5 never blew up. It is, however, not the world we live in.

That's a representation problem. C/C++ use half open ranges and have no problems with unsigned integers.

This is also a non-issue in C++ as you have iterators and counting loops are easy to abstract away using counting iterators or <algorithm> style functions.

> Third case, dealing with raw data from networks, from devices, from flash memory etc. where you actually need to manipulate every bit accurately.

I just started working on this kind of application (well, USB protocols, but same issues) in Nimrod.

First of all: just do "import unsigned" and you can work with unsigned just fine. I don't see why this is an issue, any more than that you have to do "import libusb".

Second: I found that, knowing that unsigned types are a second-class citizen lead me towards writing a much better library. It encourages you to expose only signed integers to the next level up in the app. The next thing I realized is that this will very quickly cause Nimrod programmers to write and adopt a "Protocol Buffers"-like library for dealing with network protocols, binary files and similar things. And that will be a much better solution than dealing with things like unsigned integers and endianess in manual code.

Sorry, wasn't saying it was an issue with the language, just another case where unsigned, raw data was useful.

I don't really see how unsigned are that much of a problem that they have to be dealt with specially...

I think you hit the nail on the head: the problem is education. Generally, a C programmer who took the time to understand integer types and their behaviour won't make mistakes with either signed or unsigned types. But making unsigned types second class only reinforces bad habits (or what I consider bad).

> But making unsigned types second class only reinforces bad habits (or what I consider bad).

What do you mean by that? Don't you think that having to do "import unsigned" before they use unsigned types, make some people think twice? Don't you think a few people might think "Do I really understand this feature? Should I perhaps read the documentation for this module?"

Fully agree. Lot of pogrammers misunderstands signed types which results in different bugs when combining signed with unsigned.

More importantly though, not having unsigned types, as in Java, means that we have to use 16-bit int to store a byte, 32-bit int to store a 16-bit unsiged etc.

Btw, if you check any C code, you'll notice that is vast majority of cases negative values of int are actually invalid from the business logic point of view.

  ..., not having unsigned types, as in Java, ...

Unsinged integer exist in Nimrod, you just have to

  import unsigned

when you use them.

Reply on news.ycombinator.com