Steven, I agree that neither complete context determined rules nor self-determined are appropriate. If someone wants to take a shot at writing something that is approximately correct, I'd be interested. It might end up looking something similar to some of the coverpoint bin expression rules that deal with overflow values, etc. in a special manner. I haven't spent anytime trying to figure out a good rule set. I do agree with Stu's concerns here too -- there is a legitimate concern about enum base type overflow at the least and I think we want to be careful about that. You've acknowledged that as well, so I think that it is likely just some work to find a common rule set. Whether or not the changes are within the scope/timeframe of what we can do for the ballot issues is a different question. Gord. Steven Sharp wrote: >> 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 > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri May 1 16:16:41 2009
This archive was generated by hypermail 2.1.8 : Fri May 01 2009 - 16:16:55 PDT