7 ms·

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

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.

barrkel 12y ago
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.
- DennisP 12y ago
  I don't find bitwise operations incredibly rare. I use them fairly often in my side projects (various simulations and optimizers).
- _pmf_ 12y ago
  > The places where unsigned numbers are justified are incredibly rare: bitwise operations I take it you do not work with bare metal at all.
  - audunw 12y ago
    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.
  - pjmlp 12y ago
    I take you aren't aware OP was on the Delphi compiler team and has lot of experience with low level coding.
- Nursie 12y ago
  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.
  - audunw 12y ago
    > 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.
    - Nursie 12y ago
      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...
  - rbehrends 12y ago
    > 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-signed-over-unsigned-in-c http://stackoverflow.com/questions/18795453/why-prefer-signe...
- eliteraspberrie 12y ago
  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).
  - audunw 12y ago
    > 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?"
rumcajz 12y ago
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.
- idlewan 12y ago
  ..., not having unsigned types, as in Java, ... Unsinged integer exist in Nimrod, you just have to import unsigned when you use them.

barrkel 12y ago

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.

DennisP 12y ago
I don't find bitwise operations incredibly rare. I use them fairly often in my side projects (various simulations and optimizers).
_pmf_ 12y ago
> The places where unsigned numbers are justified are incredibly rare: bitwise operations I take it you do not work with bare metal at all.
- audunw 12y ago
  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.
- pjmlp 12y ago
  I take you aren't aware OP was on the Delphi compiler team and has lot of experience with low level coding.
Nursie 12y ago
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.
- audunw 12y ago
  > 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.
  - Nursie 12y ago
    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...
- rbehrends 12y ago
  > 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-signed-over-unsigned-in-c http://stackoverflow.com/questions/18795453/why-prefer-signe...
eliteraspberrie 12y ago
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).
- audunw 12y ago
  > 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?"

rumcajz 12y ago

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.

idlewan 12y ago
..., not having unsigned types, as in Java, ... Unsinged integer exist in Nimrod, you just have to import unsigned when you use them.