Live data from Hacker News

Summary of C/C++ integer rules

nayuki.io

1–10 of 98 posts

Re: Summary of C/C++ integer rules

#2
It’s funny that you would end up with a similar conclusion for other parts of the language (e.g. operators) as well. Just a gigantic set of inane rules everywhere causing you to constantly be in danger of introducing bugs and portability issues.

Re: Summary of C/C++ integer rules

#3

It’s funny that you would end up with a similar conclusion for other parts of the language (e.g. operators) as well. Just a gigantic set of inane rules everywhere causing you to constantly be in danger of introducing bugs and portability issues.

But! And that's important -- it allows for great performance, so you can make ten/hundred times more mistakes per second than in other, "safer" languages.

Re: Summary of C/C++ integer rules

#4
> Having signed and unsigned variants of every integer type essentially doubles the number of options to choose from. This adds to the mental burden, yet has little payoff because signed types can do almost everything that unsigned ones can.

Unsigned types are quite useful when doing bit twiddling because they don't overflow or have a bit taken up by the sign.

Re: Summary of C/C++ integer rules

#6
[Dons language lawyer hat]

> floating-point number types will not be discussed at all, because that mostly deals with how to analyze and handle approximation errors that stem from rounding. By contrast, integer math is a foundation of programming and computer science, and all calculations are always exact in theory (ignoring implementations issues like overflow).

Integer overflow is no mere implementation issue, any more than errors are an implementation issue with floating-point.

> Unqualified char may be signed or unsigned, which is implementation-defined.

> Unqualified short, int, long, and long long are signed. Adding the unsigned keyword makes them unsigned.

There's an additional point here that's not mentioned: char, signed char, and unsigned char are distinct types, but that's only true of char. That is, signed int describes the same type as int. You can see this using the std::is_same type-trait with a conforming compiler. Whether char behaves like a signed integer type or an unsigned integer type, depends on the platform.

> Signed numbers may be encoded in binary as two’s complement, ones’ complement, or sign-magnitude; this is implementation-defined.

This is no longer true of C++. As of C++20, signed integer types are defined to use two's complement. [0] I don't think C intends to do the same.

> Character literals (in single quotes) have the type (signed) int in C, but (signed or unsigned) char in C++.

That's not correct. In C++, the type of a character literal is simply char, never signed char nor unsigned char. As I mentioned above, whether char is signed depends on the platform, but it's always a distinct type.

> Signed division can overflow – e.g. INT_MIN / -1.

This isn't just overflow, it's undefined behaviour.

> Counting down

> Whereas an unsigned counter would require code like:

> for (unsigned int i = len; i > 0; i--) { process(array[i - 1]); }

That's one solution, but it might be a good place for a do/while loop.

[0] https://stackoverflow.com/q/57363324/

Re: Summary of C/C++ integer rules

#7

It’s funny that you would end up with a similar conclusion for other parts of the language (e.g. operators) as well. Just a gigantic set of inane rules everywhere causing you to constantly be in danger of introducing bugs and portability issues.

It's a feature, not a bug.

Re: Summary of C/C++ integer rules

#8

It’s funny that you would end up with a similar conclusion for other parts of the language (e.g. operators) as well. Just a gigantic set of inane rules everywhere causing you to constantly be in danger of introducing bugs and portability issues.

It's more funnier that although language is full of traps, in practice it works quite well. I don't think any C developer(or let's say %95) knows all the rules mentioned in the article, yet we are still one piece.

Does anybody know any paper for bugs per lines of code for different languages or something similar?

Re: Summary of C/C++ integer rules

#9

[Dons language lawyer hat] > floating-point number types will not be discussed at all, because that mostly deals with how to analyze and handle approximation errors that stem from rounding. By contrast, integer math is a foundation of programming and computer science, and all calculations are always exact in theory (ignoring implementations issues like overflow). Integer overflow is no mere implementation issue, any…

>> Character literals (in single quotes) have the type (signed) int in C, but (signed or unsigned) char in C++.

> That's not correct. In C++, the type of a character literal is simply char, never signed char nor unsigned char.

I'd assume the author meant (signed `char` | unsigned `char`) rather than (`signed char` | `unsigned char`).

Re: Summary of C/C++ integer rules

#10

> Having signed and unsigned variants of every integer type essentially doubles the number of options to choose from. This adds to the mental burden, yet has little payoff because signed types can do almost everything that unsigned ones can. Unsigned types are quite useful when doing bit twiddling because they don't overflow or have a bit taken up by the sign.

Which is why sane languages of the time had a bitfield type.
Post reply on HN