+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C++ (https://forum.misra.org.uk/forumdisplay.php?fid=18)
+--- Forum: MISRA C++:2008 rules (https://forum.misra.org.uk/forumdisplay.php?fid=19)
+---- Forum: 6.5 Expressions (C++) (https://forum.misra.org.uk/forumdisplay.php?fid=134)
+---- Thread: Underlying type balancing for integral operands (/showthread.php?tid=1376)
Underlying type balancing for integral operands - abgs - 06-10-2017
From "Underlying type balancing" on page 57:
Quote:Otherwise, if both operands have integral type, the underlying type of the expression can be found using the following:
– If the types of the operands are the same size, and either is unsigned, the result is unsigned.
– Otherwise, the type of the result is that of the larger type.
1. Does "the types of the operands" refer to underlying type or actual type?
2. Does "and either is unsigned" mean "and either is an unsigned integral type" or "and either is the type unsigned [int]"?
3. What is the intended meaning of "the result is unsigned" in the first bullet? A literal reading might suggest that the result is simply unsigned, i.e. the type unsigned int. I do not think this is the intended behavior. I assume it was meant to have the effect as if it said "the result is the [underlying?] type of the unsigned operand(s)".
4. Does "that of the larger type" refer to underlying type or actual type?
Re: Underlying type balancing for integral operands - misra cpp - 17-01-2018
To answer your questions:
1) underlying type
2) "and either is an unsigned integral type"
3) "the result is the actual type of the unsigned operand(s)"
4) underlying type
Re: Underlying type balancing for integral operands - abgs - 21-02-2018
What is the intended interaction between 1 and 3, particularly the transition from underlying type to actual type for the "unsigned operand"? This seems to lead to strange outcomes for code like a_u16 + b_u16 + c_u16 where there are expressions whose underlying type is unsigned while the actual type is signed. The only way I see to interpret 1 and 3 together as written would be as "if the essential type of either operand is unsigned, the result is the actual type of the essentially unsigned operand". Presumably either "either is unsigned" should refer to actual type, or "the result is unsigned" should refer to the essential type of the unsigned operand. The latter seems to produce the most consistent results when applied to the rules in 6.5.
Re: Underlying type balancing for integral operands - misra cpp - 17-04-2018
The wording of our previous post could have been clearer -
for 3, its the underlying type of the result that is unsigned