Consider the following†:
size_t r = 0;
r--;
const bool result = (r == -1);
Does the comparison whose result initialises result
have well-defined behaviour?
And is its result true
, as I'd expect?
This Q&A was written because I was unsure of two factors in particular.
They may both be identified by use of the term "crucial[ly]" in my answer.
† This example is inspired by an approach for loop conditions when the counter is unsigned:for (size_t r = m.size() - 1; r != -1; r--)
size_t r = 0;
r--;
const bool result = (r == -1);
Strictly speaking, the value of result
is implementation-defined. In practice, it's almost certain to be true
; I'd be surprised if there were an implementation where it's false
.
The value of r
after r--
is the value of SIZE_MAX
, a macro defined in <stddef.h>
/ <cstddef>
.
For the comparison r == -1
, the usual arithmetic conversions are performed on both operands. The first step in the usual arithmetic conversions is to apply the integral promotions to both operands.
r
is of type size_t
, an implementation-defined unsigned integer type. -1
is an expression of type int
.
On most systems, size_t
is at least as wide as int
. On such systems, the integral promotions cause the value of r
either to be converted to unsigned int
or to keep its existing type (the former can happen if size_t
has the same width as int
, but a lower conversion rank). Now the left operand (which is unsigned) has at least the rank of the right operand (which is signed). The right operand is converted to the type of the left operand. This conversion yields the same value as r
, and so the equality comparison yields true
.
That's the "normal" case.
Suppose we have an implementation where size_t
is 16 bits (let's say it's a typedef
for unsigned short
) and int
is 32 bits. So SIZE_MAX == 65535
and INT_MAX == 2147483647
. Or we could have a 32-bit size_t
and a 64-bit int
. I doubt that any such implementation exists, but nothing in the standard forbids it (see below).
Now the left side of the comparison has type size_t
and value 65535
. Since signed int
can represent all the values of type size_t
, the integral promotions convert the value to 65535
of type int
. Both side of the ==
operator have type int
, so the usual arithmetic conversions have nothing to do. The expression is equivalent to 65535 == -1
, which is clearly false
.
As I mentioned, this kind of thing is unlikely to happen with an expression of type size_t
-- but it can easily happen with narrower unsigned types. For example, if r
is declared as an unsigned short
, or an unsigned char
, or even a plain char
on a system where that type is signed, the value of result
will probably be false
. (I say probably because short
or even unsigned char
can have the same width as int
, in which case result
will be true
.)
In practice, you can avoid the potential problem by doing the conversion explicitly rather than relying on the implementation-defined usual arithmetic conversions:
const bool result = (r == (size_t)-1);
or
const bool result = (r == SIZE_MAX);
C++11 standard references:
- 5.10 [expr.eq] Equality operators
- 5.9 [expr.rel] Relational operators (specifies that the usual arithmetic conversions are performed)
- 5 [expr] Expressions, paragraph 9: Usual arithmetic conversions
- 4.5 [conv.prom] Integral promotions
- 18.2 [support.types]
size_t
18.2 paragraphs 6-7:
6 The type
size_t
is an implementation-defined unsigned integer type that is large enough to contain the size in bytes of any object.7 [ Note: It is recommended that implementations choose types for
ptrdiff_t
andsize_t
whose integer conversion ranks (4.13) are no greater than that ofsigned long int
unless a larger size is necessary to contain all the possible values. — end note ]
So there's no prohibition on making size_t
narrower than int
. I can almost plausibly imagine a system where int
is 64 bits, but no single object can be bigger than 232-1 bytes so size_t
is 32 bits.
Yes, and the result is what you would expect.
Let's break it down.
What is the value of r
at this point? Well, the underflow is well-defined and results in r
taking on its maximum value by the time the comparison is run. std::size_t
has no specific known bounds, but we can make reasonable assumptions about its range when compared to that of an int
:
std::size_t
is the unsigned integer type of the result of the sizeof operator. [..]std::size_t
can store the maximum size of a theoretically possible object of any type (including array).
And, just to get it out of the way, the expression -1
is unary -
applied to the literal 1
, and has type int
on any system:
[C++11: 2.14.2/2]:
The type of an integer literal is the first of the corresponding list in Table 6 in which its value can be represented. [..]
(I won't cite all the text that describes how applying unary -
to an int
results in an int
, but it does.)
It's more than reasonable to suggest that, on the majority of systems, an int
is not going to be able to hold std::numeric_limits<std::size_t>::max()
.
Now, what happens to those operands?
[C++11: 5.10/1]:
The==
(equal to) and the!=
(not equal to) operators have the same semantic restrictions, conversions, and result type as the relational operators except for their lower precedence and truth-value result. [..]
[C++11: 5.9/2]:
The usual arithmetic conversions are performed on operands of arithmetic or enumeration type. [..]
Let's examine these "usual arithmetic conversions":
[C++11: 5/9]:
Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result.This pattern is called the usual arithmetic conversions, which are defined as follows:
- If either operand is of scoped enumeration type (7.2), no conversions are performed; if the other operand does not have the same type, the expression is ill-formed.
- If either operand is of type
long double
, the other shall be converted to long double`.- Otherwise, if either operand is
double
, the other shall be converted todouble
.- Otherwise, if either operand is
float
, the other shall be converted tofloat
.- Otherwise, the integral promotions (4.5) shall be performed on both operands.59 Then the following rules shall be applied to the promoted operands:
- If both operands have the same type, no further conversion is needed.
- Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank shall be converted to the type of the operand with greater rank.
- Otherwise, if the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type shall be converted to the type of the operand with unsigned integer type.
- Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type shall be converted to the type of the operand with signed integer type.
- Otherwise, both operands shall be converted to the unsigned integer type corresponding to the type of the operand with signed integer type.
I've highlighted the passage that takes effect here and, as for why:
[C++11: 4.13/1]
: Every integer type has an integer conversion rank defined as follows
- [..]
- The rank of
long long int
shall be greater than the rank oflong int
, which shall be greater than the rank ofint
, which shall be greater than the rank ofshort int
, which shall be greater than the rank ofsigned char
.- The rank of any unsigned integer type shall equal the rank of the corresponding signed integer type.
- [..]
All integral types, even the fixed-width ones, are composed of the standard integral types; therefore, logically, std::size_t
must be unsigned long long
, unsigned long
, or unsigned int
.
If
std::size_t
isunsigned long long
, orunsigned long
, then the rank ofstd::size_t
is greater than the rank ofunsigned int
and, therefore, also ofint
.If
std::size_t
isunsigned int
, the rank ofstd::size_t
is equal to the rank ofunsigned int
and, therefore, also ofint
.
Either way, per the usual arithmetic conversions, the signed operand is converted to the type of the unsigned operand (and, crucially, not the other way around!). Now, what does this conversion entail?
[C++11: 4.7/2]:
If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type). [ Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). —end note ]
[C++11: 4.7/3]:
If the destination type is signed, the value is unchanged if it can be represented in the destination type (and bit-field width); otherwise, the value is implementation-defined.
This means that std::size_t(-1)
is equivalent to std::numeric_limits<std::size_t>::max()
; it's crucial that the value n in the above clause relates to the number of bits used to represent the unsigned type, not the source type. Otherwise, we'd be doing std::size_t((unsigned int)-1)
, which is not the same thing at all — it could be many orders of magnitude smaller than our desired value!
Indeed, now that we know the conversions are all well-defined, we can test this value:
std::cout << (std::size_t(-1) == std::numeric_limits<size_t>::max()) << '\n';
// "1"
And, just to illustrate my point from earlier, on my 64-bit system:
std::cout << std::is_same<unsigned long, std::size_t>::value << '\n';
std::cout << std::is_same<unsigned long, unsigned int>::value << '\n';
std::cout << std::hex << std::showbase
<< std::size_t(-1) << ' '
<< std::size_t(static_cast<unsigned int>(-1)) << '\n';
// "1"
// "0"
// "0xffffffffffffffff 0xffffffff"
来源:https://stackoverflow.com/questions/27405418/is-comparing-an-underflowed-unsigned-integer-to-1-well-defined