RE: [sv-bc] FW: Manti 1345, 1711: unique if/case

From: Steven Sharp <sharp_at_.....>
Date: Fri Nov 16 2007 - 17:16:33 PST
>From: "Bresticker, Shalom" <shalom.bresticker@intel.com>

>Regarding Item 6 below, please indicate whether you prefer option A or
>option B.
>
>	6. Side-effects: Unique is not intended for use with
>side-effects. In my view, someone who tries it deserves whatever he
>gets, and probably deserves worse than that. For simplicity, I'd like to
>suggest one of the following:
>
>	A. Keep the statement that the case_item expressions can be
>evaluated and compared in any order, with the statements about optional
>short-circuiting. If a case_item expression has a side-effect, the
>side-effect occurs when the expression is evaluated, so no book-keeping
>needed. Add a statement that if case_item expressions contain
>side-effects, then because the order is not specified and
>short-circuiting may or may not occur, it is not determinate which
>side-effects will occur, and the results may therefore be unexpected
>and/or undesirable.
>
>	B. Specify the order of evaluation and comparison to be like
>that of plain and priority cases, in order of appearance (see also
>Mantis 1041), except that in unique case, evaluations and comparisons
>continue after the first match until the end of the case or until a
>uniqueness violation is found. (Evaluations might still continue even
>after a violation is found.) Side-effects occur as the case_item
>expressions are evaluated. Short-circuiting can still occur. Again,
>without side effects, the order does not matter, so we can arbitrarily
>decide on the order. Another advantage of this is for debug. Suppose
>case_items 1, 2, and 3 all match the case_expression in a uniqueness
>violation. I'd expect the tool to report that there is a multiple match
>in items 1 and 2 or in items 1, 2, and 3. I'd be surprised if the tool
>reported that 2 and 3 match without reporting 1, but that could happen
>if the tool can choose any order.

I am OK with either option.

I am even OK with specifying that short-circuiting of evaluation of case
item expressions for a single case item is required.  I would not want
the LRM to require the reverse, evaluating all the case item expressions
after one matches.  That is unnecessary and inefficient.

I could accept specifying that short-circuiting must or must not occur
when a violation is found.

I have a slight preference for defining the behavior more precisely,
rather than leaving it unknown.  So I would prefer option B, plus
specifying the short-circuiting.  While I agree that using side-effects
is a bad idea, I don't think we should be trying to deliberately punish
someone for doing it.  I don't know that making the behavior undefined
is going to discourage someone from doing it.

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 Nov 16 17:16:53 2007

This archive was generated by hypermail 2.1.8 : Fri Nov 16 2007 - 19:20:52 PST