3 ms·
Well, it does look like a gcc bug at first glance. It's no surprise that the constant involved is 2*1024^3, since that's the maximum value it expects n can eve
by tokenrove 13y ago
Well, it does look like a gcc bug at first glance. It's no surprise that the constant involved is 2*1024^3, since that's the maximum value it expects n can ever be. Since gcc assumes signed integer arithmetic does not overflow for optimization purposes, it's usually a better idea to use unsigned types (such as size_t) for natural numbers like len, n, and i, and I would assume your code would compile fine with size_t instead of int. Removing the check of len against 1024^3 would probably also stop this behavior from happening.
- uaygsfdbzf 13y agoThanks for confirming. > Removing the check of len against 1024^3 would probably also stop this behavior from happening. Yes, removing it or even checking against 1024 instead of 1024^3 is preventing the bug. Strange behaviour. > it's usually a better idea to use unsigned types (such as size_t) for natural numbers like len, n, and i, and I would assume your code would compile fine with size_t instead of int. When I don't need all the space of the unsigned type I like to use signed types to be able to return -1 as an indication of error. Well, should we report a bug?