Integral conversions bug

Question

// integral_conversions.cpp
#include <cassert>
int main()
  unsigned long bundle_loc_mask = ( unsigned long )0 | -1;
  assert( bundle_loc_mask == 0x00000000ffffffffUL );
  return 0;
}CC -xarch=v9 integral_conversions.cpp
1 is an integer literal. - is a unary operator. If an integer literal is not suffixed, its type is int, so 1 is an int. Therefore, the expression should behave something like this.
( ( ( (unsigned long) ( (int) 0 ) ) )  |  ( - ( (int) 1) ) )The ANSI/ISO C++ standard (INCITS/ISO/IEC 14882-2003) says
"The operand of the unary - operator shall have arithmetic or enumeration type and the result is the negation of its operand. Integral promotion is performed on integral or numeration operands. The negative of an unsigned quantity is computed by subtracting its value from 2^n, where n is the number of bits in the promoted operand. The type of the result is the type of the promoted operand."
What do they mean by "integral promotion"?
"An rvalue of type char, signed char, unsigned char, short int, or unsigned short int can be converted to an rvalue of type int if int can represent all the values of the source type; otherwise, the source rvalue can be converted to an rvalue of type unsigned int."
The number of bits in the promoted operand, 1, is 32.
( - ( (int) 1) ) )becomes
0xffffffffNow we look at the left operand of the bitwise inclusive OR and see that we need promotion of the right operand.
(unsigned long)0xffffffffThe implicit conversion is governed by the rules for integral conversion in the standard.
"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). ]"
Therefore, the assertion in the above program should not fail.
Alan Feldstein
Cosmic Horizon
http://www.alanfeldstein.com/

Answer 1

The expression to the right of the bitwise inclusive OR operator is
-1That expression is also a representation of a value (i.e. it results in a value), in this case a signed decimal integer representation. Let's take a closer look at that expression. It is a sequence of operators and operands.
The operand is 1, a decimal integer literal. Section 2.13.1 paragraph 2 states that "if it is decimal and has no suffix, it has the first of these types in which its value can be represented: int, long int". In this case its type is int (i.e. a signed integer type).
Because of the -xarch=v9 option,
sizeof(int) == 4A two's complement representation of the value of the operand is
0x00000001In fact, the SPARC-V9 architecture requires that signed integer values be stored as two's-complement numbers, and a 32-bit signed integer is one of the architecture's fundamental data types. Therefore, the above representation is convenient for visualization of the value as stored.
As I said, the expression to the right of the bitwise inclusive OR operator is a sequence of operators and operands.
The operator is -, a unary operator. Section 5.3.1 paragraph 7 states that
"The operand of the unary - operator shall have arithmetic or enumeration type and the result is the negation of its operand. Integral promotion is performed on integral or enumeration operands. The negative of an unsigned quantity is computed by subtracting its value from 2**n, where n is the number of bits in the promoted operand. The type of the result is the type of the promoted operand."
In this case, the operand, 1, has arithmetic type. The result is the negation of 1. Integral promotion (Section 4.5) is not necessary on 1 because its type is int. Therefore, the "promoted" operand is 1 and its type is int. The number of bits in the promoted operand is 32. The negative of 1 is computed by subtracting its value from
0x100000000The result is
0xffffffffThe type of the result is int. Yes, this is a two's complement representation (convenient for visualization of the value as stored).
All of this has been about the expression to the right of the bitwise inclusive OR operator. Now let's take that result as an input into Section 4.7 paragraph 2.
( unsigned long )0 | 0xffffffffThis expression is equivalent to the original expression, this time written with a hexadecimal integer literal.
As for that hexadecimal integer literal to the right of the bitwise inclusive OR operator, Section 2.13.1 paragraph 2 proves that it has the same type as
-1"If it is octal or hexadecimal and has no suffix, it has the first of these types in which its value can be represented: int, unsigned int, long int, unsigned long int." In this case, it is hexadecimal and its type is int (i.e. a signed integer type).
Section 4.7 paragraph 2 describes how to perform the required integral conversion of the operand to the right of the bitwise inclusive OR operator in the following expression.
( unsigned long )0 | 0xffffffffThe destination type is unsigned.
"The resulting value is the least unsigned integer congruent to the source integer (modulo 2**n where n is the number of bits used to represent the unsigned type)."
Because of the -xarch=v9 option,
sizeof(unsigned long) == 8The number of bits used to represent the unsigned type is 64. The resulting value is the least unsigned integer congruent to
0xffffffffmodulo
0x10000000000000000Congruence requires that
resultingValue % 0x10000000000000000 == 0xffffffff % 0x10000000000000000The least unsigned long for which congruence is satisfied is
0x00000000ffffffffNote that there is no change in the bit pattern.