>From: Gordon Vreugdenhil <gordonv@model.com> >At this point, I think the self-determined context rules are actually >close to the original intent. In other words, if the self-determined >size is not the same as the enum base, it is an error. There are >some issues in that rule regarding unsized, but I think the >original intent was to have a stronger certainty about the value >domain (particularly with auto incrementing enums) than is really >possible with general context-determined evaluation. I don't think you can just dismiss the part about unsized. This rule does not allow the unsized constant case that is apparently allowed, and it is not clear how it could be generalized to do so. I also think there are other problems with trying to use a self- determined context and requiring an exact size match. What if the user is trying to create an enum with a parameterized base type, perhaps using a parameterized name[N] or name[N:M] syntax for some of the enum literals so that the number of enum literals is also parameterized? If they want to specify values for some of the literals, this rule would require them to specify a value with a width that exactly matched the parameterized base type. They would have to start jumping through hoops to satisfy that, instead of just providing an expression and letting the context-determined size rules take care of sizing. >So, I am opposed to making the enum exactly like a parameter (with >context determined semantics) but would not oppose some clarification >to the sizing rules that are present and still normative. The present rule refers explicitly to a "different sized constant". In the 2009 LRM, we use the term "literal constant", but the present rule was based on the 1364-2005 LRM. In that LRM, the "literal" had not been added to the term yet. This rule is referring to what is now called a sized literal constant. Any other case was not disallowed by this rule. There is a separate rule that says any value that is outside the representable range of the enum shall be an error. That covers the case of a larger value that does not fit. This seems to be the main rule to prevent overflow. The rule about the "different sized constant" seems to be an additional check for the case where the user was trying to use a literal of the appropriate size, but seems to be wrong. So my understanding of the present rules is consistent with evaluating the values with context determined semantics, but having a check for overflow if there is a truncation, plus a special rule when the expression is simply a sized literal. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri May 1 15:48:27 2009
This archive was generated by hypermail 2.1.8 : Fri May 01 2009 - 15:48:58 PDT