19-09-2017, 04:14 PM
Section D.6 says "If the standard type of an integer constant is unsigned int then its essential type is the UTLR." Then:
- The essential type of the integer literal 5U is unsigned char because the standard type is unsigned int and unsigned char is the smallest unsigned type capable of representing the value 5.
- The essential type of the integer literal 5UL is unsigned long because the standard type of the integer constant is not unsigned int and so the rule under the heading "Integer constants" has no effect.
Section D.7 describes the essential type of "Operations subject to the usual arithmetic conversions". Specifically, it says that "if the operands are both essentially unsigned then ... If the expression is an integer constant expression then the essential type of the result is the UTLR of the result", where "UTLR" is defined in D.3 as "the unsigned type having the lowest rank required to represent the value of a particular integer constant expression or the maximum value of a bit-field." Note in particular the absence of any restriction based on the standard type, unlike in the rule for literals. Then:
- The essential type of the integer constant expression 5U*5U is unsigned char because it is the unsigned type of lowest rank capable of representing the value 25.
- The essential type of the integer constant expression 5UL*5UL is also unsigned char because it is the unsigned type of lowest rank capable of representing the value 25.
The last conclusion regarding 5UL*5UL is complicated by the seemingly contradictory observation made in D.1 that "The essential type of an expression only differs from the standard C type (standard type) in expressions where the standard type is either signed int or unsigned int." while the standard type of this expression is unsigned long. If this passive statement is taken as a restriction on all other rules determining essential type (despite this not being stated) then there would be several strange effects:
- The essential type of the integer constant expression (uint32_t)(5U*5U) would differ depending on whether the typedef uint32_t is defined as "unsigned int" or "unsigned long", even if both are unsigned 32-bit integer types.
- The rules for the essential type of a bit-field in D.4 would no longer apply to bit-fields of type "unsigned long" if supported by the implementation, despite being explicitly permitted by rule 6.1.
- The explicit restriction that the essential type of an integer constant of unsigned type is only the UTLR when standard type is unsigned int in D.6 would be redundant.
- The essential type of the expression 'c'+1UL is specified to be char in D.2, but the standard type is not int nor unsigned int.
So my questions are:
- Is the essential type of 5U unsigned char?
- Is the essential type of 5UL unsigned long?
- Is the essential type of 5U*5U unsigned char?
- Is the essential type of 5UL*5UL unsigned char or unsigned long?
- Does the essential type of (uint32_t)(5U*5U) depend on whether uint32_t is defined as unsigned int or unsigned long if both are 32-bit unsigned integer types?
- Is the essential type of an expression referring to the value of a bit-field implemented using unsigned long in a C99 compiler that allows this the UTLR for the maximum value of the bitfield, or unsigned long?
- Is this sentence in D.1 intended to have any normative effect, and if so what is it and what is its scope? "The essential type of an expression only differs from the standard C type (standard type) in expressions where the standard type is either signed int or unsigned int."
- If the preceding phrase from D.1 does have a normative effect, is the reference to the specific standard type rather than merely the signedness in the phrase "If the standard type of an integer constant is unsigned int" in D.6 redundant?
- Is the essential type of the expression 'c'+1UL char as stated in D.2, or unsigned long if essential types cannot differ from standard types when the standard type is not signed/unsigned int as noted in D.1?
- The essential type of the integer literal 5U is unsigned char because the standard type is unsigned int and unsigned char is the smallest unsigned type capable of representing the value 5.
- The essential type of the integer literal 5UL is unsigned long because the standard type of the integer constant is not unsigned int and so the rule under the heading "Integer constants" has no effect.
Section D.7 describes the essential type of "Operations subject to the usual arithmetic conversions". Specifically, it says that "if the operands are both essentially unsigned then ... If the expression is an integer constant expression then the essential type of the result is the UTLR of the result", where "UTLR" is defined in D.3 as "the unsigned type having the lowest rank required to represent the value of a particular integer constant expression or the maximum value of a bit-field." Note in particular the absence of any restriction based on the standard type, unlike in the rule for literals. Then:
- The essential type of the integer constant expression 5U*5U is unsigned char because it is the unsigned type of lowest rank capable of representing the value 25.
- The essential type of the integer constant expression 5UL*5UL is also unsigned char because it is the unsigned type of lowest rank capable of representing the value 25.
The last conclusion regarding 5UL*5UL is complicated by the seemingly contradictory observation made in D.1 that "The essential type of an expression only differs from the standard C type (standard type) in expressions where the standard type is either signed int or unsigned int." while the standard type of this expression is unsigned long. If this passive statement is taken as a restriction on all other rules determining essential type (despite this not being stated) then there would be several strange effects:
- The essential type of the integer constant expression (uint32_t)(5U*5U) would differ depending on whether the typedef uint32_t is defined as "unsigned int" or "unsigned long", even if both are unsigned 32-bit integer types.
- The rules for the essential type of a bit-field in D.4 would no longer apply to bit-fields of type "unsigned long" if supported by the implementation, despite being explicitly permitted by rule 6.1.
- The explicit restriction that the essential type of an integer constant of unsigned type is only the UTLR when standard type is unsigned int in D.6 would be redundant.
- The essential type of the expression 'c'+1UL is specified to be char in D.2, but the standard type is not int nor unsigned int.
So my questions are:
- Is the essential type of 5U unsigned char?
- Is the essential type of 5UL unsigned long?
- Is the essential type of 5U*5U unsigned char?
- Is the essential type of 5UL*5UL unsigned char or unsigned long?
- Does the essential type of (uint32_t)(5U*5U) depend on whether uint32_t is defined as unsigned int or unsigned long if both are 32-bit unsigned integer types?
- Is the essential type of an expression referring to the value of a bit-field implemented using unsigned long in a C99 compiler that allows this the UTLR for the maximum value of the bitfield, or unsigned long?
- Is this sentence in D.1 intended to have any normative effect, and if so what is it and what is its scope? "The essential type of an expression only differs from the standard C type (standard type) in expressions where the standard type is either signed int or unsigned int."
- If the preceding phrase from D.1 does have a normative effect, is the reference to the specific standard type rather than merely the signedness in the phrase "If the standard type of an integer constant is unsigned int" in D.6 redundant?
- Is the essential type of the expression 'c'+1UL char as stated in D.2, or unsigned long if essential types cannot differ from standard types when the standard type is not signed/unsigned int as noted in D.1?
<t></t>