Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Summary of C/C++ integer rules

nayuki.io

Post reply on HN
Print view View original

91–98 of 98 posts

Re: Summary of C/C++ integer rules

#91

Post by UncleMeat »

dkersten wrote: post #74
UncleMeat wrote: post #66

Earlier quoted context omitted.

But "unsigned" doesn't actually enforce the semantics you want. Missing an overflow check means your value will never be negative, but it is almost certainly still a bug. And because unsigned overflow is defined, the compiler isn't allowed to prevent you from doing it! This is just enough type semantics to injure oneself.

So, because its not perfect, should you throw it all out?

No. Because people tend to make more mistakes if they try to use unsigned values in this manner in C/C++.

Re: Summary of C/C++ integer rules

#92

Post by rurban »

jeffbee wrote: post #67
flohofwoe wrote: post #13

In the myths section: > char is always 8 bits wide. int is always 32 bits wide > Signed overflow is guaranteed to be wrap around. (e.g. INT_MAX + 1 == INT_MIN.) Are there any current, relevant hardware architectures where this is not true (e.g. bytes are not 8 bits, and integers are not 2's complement)? E.g. what's the point of "portability" if there is no physical hardware around anymore where those restrictions wou…

There are loads of DSPs, MCUs, and other non-PC junk where CHAR_BIT is not 8. For example of the SHARC, CHAR_BIT is 32, absolutely every type is 32 bits wide.

So they can actually support raw strings! Nice

Re: Summary of C/C++ integer rules

#93

Post by dkersten »

UncleMeat wrote: post #91
dkersten wrote: post #74

Earlier quoted context omitted.

So, because its not perfect, should you throw it all out?

No. Because people tend to make more mistakes if they try to use unsigned values in this manner in C/C++.

I’ve personally never encountered a bug that turned out to be caused by an unsigned value. YMMV, I guess.

Re: Summary of C/C++ integer rules

#94

Post by UncleMeat »

dkersten wrote: post #93
UncleMeat wrote: post #91

Earlier quoted context omitted.

No. Because people tend to make more mistakes if they try to use unsigned values in this manner in C/C++.

I’ve personally never encountered a bug that turned out to be caused by an unsigned value. YMMV, I guess.

If seen all sorts of bugs caused by surprise conversions, as well as overflows that cause bugs that would be statically detectable but can't become blocking errors because unsigned overflow is well defined.

Re: Summary of C/C++ integer rules

#95

Post by nayuki »

dataflow wrote: post #9
MaxBarraclough wrote: post #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…

>> 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`).

To put it better, I meant to write that C++ character literals have type `char`, which in turn maps to either `signed char` or `unsigned char`.

Re: Summary of C/C++ integer rules

#96

Post by nayuki »

masklinn wrote: post #53
enriquto wrote: post #52

Earlier quoted context omitted.

Positive values are a particular case of signed values, you can still use signed ints to store positive values. No need to enforce your semantics through type, and especially not when the values of the type are trivially particular cases of the values of another type. For example, when you write a function in C that computes prime factors of an int, do you need a type for prime numbers? No, you just use int. The same…

> Positive values are a particular case of signed values, you can still use signed ints to store positive values. And yet Java's lack of unsigned integers is considered a major example of its (numerous) design errors. > No need to enforce your semantics through type, and especially not when the values of the type are trivially particular cases of the values of another type. Of course not, there's no need for any type…

Java's lack of unsigned int is widely (but not universally) seen as a deficiency. This is especially true when Java is compared to C#, a very similar language at its core but which does have uint types. Anyway, I have a separate article arguing why Java should not have uint, and many ideas from there can be adapted to C/C++ too: https://www.nayuki.io/page/unsigned-int-considered-harmful-f...

Re: Summary of C/C++ integer rules

#97

Post by nayuki »

dusanz wrote: post #48
dahfizz wrote: post #37

One thing I think should have been mentioned: size_t is guaranteed to be large enough to index all of memory, which is why it is the return type of size of.

size_t is only guaranteed to be large enough to store the size of the largest object. This is not the same as being able to index all of memory. You could imagine a platform with restricted continuous allocation size where the maximum object size is smaller than the size of the address space.

Furthermore, size_t bears no relationship with int; it could be wider/equal/narrower. If size_t is narrower than int, then doing any arithmetic on size_t variables will result in automatic promotion to signed int, which can lead to dangerous signed overflow. C/C++ are full of footguns.

Re: Summary of C/C++ integer rules

#98

Post by nayuki »

tammerk wrote: post #8
dreinhardt wrote: post #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.

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?

C/C++ developers not knowing the rules does bite them. For example, it made the 32-bit/64-bit transition much more painful. See https://www.viva64.com/en/a/0004/ ; https://www.viva64.com/en/a/0065/
Post reply on HN