I was looking at this video. Bjarne Stroustrup says that unsigned ints are error prone and lead to bugs. So, you should only use them when you really need them. I've also read in one of the question on Stack Overflow (but I don't remember which one) that using unsigned ints can lead to security bugs.
How do they lead to security bugs? Can someone clearly explain it by giving an suitable example?
One possible aspect is that unsigned integers can lead to somewhat hard-to-spot problems in loops, because the underflow leads to large numbers. I cannot count (even with an unsigned integer!) how many times I made a variant of this bug
for(size_t i = foo.size(); i >= 0; --i)
...
Note that, by definition, i >= 0 is always true. (What causes this in the first place is that if i is signed, the compiler will warn about a possible overflow with the size_t of size()).
There are other reasons mentioned Danger – unsigned types used here!, the strongest of which, in my opinion, is the implicit type conversion between signed and unsigned.
operator--> ( go down to ): for (size_t i = sz; i --> 0;) ... iterates from sz-1 to 0 –
Ibiza One big factor is that it makes loop logic harder: Imagine you want to iterate over all but the last element of an array (which does happen in the real world). So you write your function:
void fun (const std::vector<int> &vec) {
for (std::size_t i = 0; i < vec.size() - 1; ++i)
do_something(vec[i]);
}
Looks good, doesn't it? It even compiles cleanly with very high warning levels! (Live) So you put this in your code, all tests run smoothly and you forget about it.
Now, later on, somebody comes along an passes an empty vector to your function. Now with a signed integer, you hopefully would have noticed the sign-compare compiler warning, introduced the appropriate cast and not have published the buggy code in the first place.
But in your implementation with the unsigned integer, you wrap and the loop condition becomes i < SIZE_T_MAX. Disaster, UB and most likely crash!
I want to know how they lead to security bugs?
This is also a security problem, in particular it is a buffer overflow. One way to possibly exploit this would be if do_something would do something that can be observed by the attacker. They might be able to find what input went into do_something, and that way data the attacker should not be able to access would be leaked from your memory. This would be a scenario similar to the Heartbleed bug. (Thanks to ratchet freak for pointing that out in a comment.)
vector could be a member of a class where the last element depends on the n previous one. Now, if n == 0, you do not need the last element either, so you leave the vector empty. Our algorithm at hand never handles the last element, so we have the loop I showed. But I still admit such thing never happened in any code I actually saw (probably bc I wrote most of the code I've seen so far, and I don't do such things). –
Pulpboard n depends on elements [0, n), and there'd be no problem with signedness :-S –
Cragsman for (std::size_t i = 0; i + 1 < vec.size(); ++i)? –
Escape new[] vs std::vector. –
Pulpboard int, but will fit in an unsigned int, optimal semantics would have been obtained by having size_t be a type which is stored in unsigned-int format, but promotes to long on rvalue conversion. Having such sizes using one word rather than two is beneficial, but the present rules which cause calculations involving them to be evaluated using modular arithmetic are far less so. –
Riot unsigned int is a perfectly fine variable type in cases where one wants to perform modular arithmetic, but it is a semantically inappropriate [not "bad"] type in cases where one is representing quantities. –
Riot I'm not going to watch a video just to answer a question, but one issue is the confusing conversions which can happen if you mix signed and unsigned values. For example:
#include <iostream>
int main() {
unsigned n = 42;
int i = -42;
if (i < n) {
std::cout << "All is well\n";
} else {
std::cout << "ARITHMETIC IS BROKEN!\n";
}
}
The promotion rules mean that i is converted to unsigned for the comparison, giving a large positive number and a surprising result.
unsigned n=2; int i=-1, j=1; One will then observe that n < i, i < j, and j < n are all true. –
Riot i to unsigned is harder to avoid if you are producing an integer result, but for a comparison it is trivial to define the language correctly. Even COBOL had has On size error, but C(++) just gives you enough rope to hang yourself! On VMS, DEC C (don’t know about ++) warns about signed/unsigned comparison/assignment, quite right too (given the broken language), –
Grassgreen -Wall -Wextra -pedantic -Wconversion -Wshadow -Werror (my personal minimal list of warning flags) it is your own fault really... (even without the -Werror you would get a warning. only without -Wall would you not get a warning - and that is just evil) –
Computer Although it may only be considered as a variant of the existing answers: Referring to "Signed and unsigned types in interfaces," C++ Report, September 1995 by Scott Meyers, it's particularly important to avoid unsigned types in interfaces.
The problem is that it becomes impossible to detect certain errors that clients of the interface could make (and if they could make them, they will make them).
The example given there is:
template <class T> class Array { public: Array(unsigned int size); ...
and a possible instantiation of this class
int f(); // f and g are functions that return int g(); // ints; what they do is unimportant Array<double> a(f()-g()); // array size is f()-g()
The difference of the values returned by f() and g() might be negative, for an awful number of reasons. The constructor of the Array class will receive this difference as a value that is implicitly converted to be unsigned. Thus, as the implementor of the Array class, one can not distinguish between an erreonously passed value of -1, and a very large array allocation.
Array<double>(*ptrToSize). –
Manofwar assert(ptr != nullptr) could be sufficient there. Something like assert(size < theSizeThatIsLikelyToBeAllocated) doesn't work. Of course, one could still misuse the API with signed types. It's just harder, and the likeliest errors (that are caused by things like implicit conversions) can be covered. –
Homeopathy The big problem with unsigned int is that if you subtract 1 from an unsigned int 0, the result isn't a negative number, the result isn't less than the number you started with, but the result is the largest possible unsigned int value.
unsigned int x = 0;
unsigned int y = x - 1;
if (y > x) printf ("What a surprise! \n");
And this is what makes unsigned int error prone. Of course unsigned int works exactly as it is designed to work. It's absolutely safe if you know what you are doing and make no mistakes. But most people make mistakes.
If you are using a good compiler, you turn on all the warnings that the compiler produces, and it will tell you when you do dangerous things that are likely to be mistakes.
uint32_t x,y,z; expressions like x-y > z will have very different meanings on 32-bit and 64-bit systems. –
Riot int is 64 bits. IMHO the Standard would have benefited from defining non-promoting types whose behavior would be consistent on all compilers that accepted code using them. Operations that use wrap32_t should either yield a result of that type when possible, or refuse compilation altogether (e.g. because the compiler doesn't support the required semantics, or because e.g. code is trying to add a wrap16_t and wrap32_t together--an action that cannot possibly yield a result satisfying both constraints). –
Riot The problem with unsigned integer types is that depending upon their size they may represent one of two different things:
int (e.g. uint8) hold numbers in the range 0..2ⁿ-1, and calculations with them will behave according to the rules of integer arithmetic provided they don't exceed the range of the int type. Under present rules, if such a calculation exceeds the range of an int, a compiler is allowed to do anything it likes with the code, even going so far as to negate the laws of time and causality (some compilers will do precisely that!), and even if the result of the calculation would be assigned back to an unsigned type smaller than int. unsigned int and larger hold members of the abstract wrapping algebraic ring of integers congruent mod 2ⁿ; this effectively means that if a calculation goes outside the range 0..2ⁿ-1, the system will add or subtract whatever multiple of 2ⁿ would be required to get the value back in range.Consequently, given uint32_t x=1, y=2; the expression x-y may have one of two meanings depending upon whether int is larger than 32 bits.
int is larger than 32 bits, the expression will subtract the number 2 from the number 1, yielding the number -1. Note that while a variable of type uint32_t can't hold the value -1 regardless of the size of int, and storing either -1 would cause such a variable to hold 0xFFFFFFFF, but unless or until the value is coerced to an unsigned type it will behave like the signed quantity -1.int is 32 bits or smaller, the expression will yield a uint32_t value which, when added to the uint32_t value 2, will yield the uint32_t value 1 (i.e. the uint32_t value 0xFFFFFFFF).IMHO, this problem could be solved cleanly if C and C++ were to define new unsigned types [e.g. unum32_t and uwrap32_t] such that a unum32_t would always behave as a number, regardless of the size of int (possibly requiring the right-hand operation of a subtraction or unary minus to be promoted to the next larger signed type if int is 32 bits or smaller), while a wrap32_t would always behave as a member of an algebraic ring (blocking promotions even if int were larger than 32 bits). In the absence of such types, however, it's often impossible to write code which is both portable and clean, since portable code will often require type coercions all over the place.
int? –
Plainspoken int are a complete PITA, unsigned ones especially so. –
Madras uint32_t as behaving like one of two very different types depending upon the size of int? I wouldn't call integer types smaller than int a PITA in cases where one is expecting them to behave like numbers within their legitimate range. What's problematic are types that are smaller than int on some platforms but not others; the only advantage I see to having the behavior change depending upon int size is that it allows existing code written for particular int sizes to work on systems where int size is as expected. –
Riot int will get promoted to signed int whenever any calculations are performed on them. On common 32-bit machines, this is most widely observable with types uint8_t and uint16_t. Promotion to int is often useful when the unsigned values represent quantities, but can be disastrous in cases where they represent things that are supposed to wrap. Note that given uint16_t x=65533; x*=x; a compiler for a system where unsigned int is 16 bits, or where it is larger than 32 bits, must set x=9, but on a system where unsigned is 17 to 32 bits... –
Riot uint16_t, or performing it in an int type large enough to hold 4294574089 and storing to uint16_t, will yield 9). If the value gets promoted to an int type that can't hold 4294574089, though, the overflow may have consequences far beyond the value of x. –
Riot Numeric conversion rules in C and C++ are a byzantine mess. Using unsigned types exposes yourself to that mess to a much greater extent than using purely signed types.
Take for example the simple case of a comparison between two variables, one signed and the other unsigned.
To take another example consider multiplying two unsigned integers of the same size.
In addition to range/warp issue with unsigned types. Using mix of unsigned and signed integer types impact significant performance issue for processor. Less then floating point cast, but quite a lot to ignore that. Additionally compiler may place range check for the value and change the behavior of further checks.
unsigned to int or vice versa the binary representations identify exactly. So there is no overhead for the CPU when you cast the one to the other. –
Computer © 2022 - 2024 — McMap. All rights reserved.
intis 32 bits, calculations onintthat overflow must yield values which are congruent to the correct results mod 2³², but were not required to behave as values within... – Riotint32_t x=INT32_MAX; x++; int64_t y1=x,y2=x;a compiler would not be required to assign the same value toy1andy2, but castingy1andy2both touin32_twould be required to give the same value, i.e. (INT32_MAX + 1u). I would expect explicit checked-integer semantics could allow some very useful optimizations if the compiler were allowed to hold correct calculations beyond specified precision, and only had to trap when precision was lost. Givenicheck32_t w,x,y,z;, the expressionw=x+y+z;... – Riotx+yand(x+y)+zwere representable inicheck32_t, but the compiler would be free to trap or not at its leisure ifx+ywas not representable butx+y+zwas. – Riot