[sv-ec] RE: Manti 2701, 2514 - response to Tom Alsop's feedback

From: Alsop, Thomas R <thomas.r.alsop_at_.....>
Date: Wed Apr 29 2009 - 10:21:34 PDT
Thanks Jonathon, my comments below. -Tom



> 2.       The third sentence states that ?For any such violating

> operation, a warning shall be issued?, but then the next sentence it

states ?

> Tools should issue exactly one warning?.  In clause 1.5 the

> conventions for ?shall?, ?should?, ?may?, and ?can? are clear.  I

> just want to make sure we are being clear in this new sub-clause WRT

> to these conventions. Seems like the 4th sentence should read that

> ?Implementations shall issue exactly one warning??



Given



  int Q2[$:1]; // only [0:1] is allowed

  Q2 = {0,1,2,3};



I don't want to see TWO warnings, for the failed

attempts to write Q2[2] and Q2[3].  Just one warning

each time the assignment is executed.  I used "should"

here as an opt-out in case this proves hard to implement

in some situations; the previous sentence's "shall issue

a warning" obliges tools to produce at least one, but it's

highly preferable that there should be exactly one.  If all

the vendors are OK with it, I'd happily change "should"

to "shall" here.

[Alsop, Thomas R] Yeah, the root of the issue here then is do we want to see all the violations or just one of them.  If there are hundreds or thousands of violations then this gets ugly, but generally speaking I think the majority of the cases will only see one or a handful of violations.  IMHO, I always want to see _all_ the violations at once so I can fix them without having to iterate.  On the implementation (tool:)) side I would tend to believe that it will be easier to spit out all the violations, else you have to implement a 'print once' check, so that successive prints don't happen, which makes the code more complicated, albeit a minor complication. My preference is to change this to 'shall', but I'll defer to the tool experts.



> 3.       This sentence really confused me ?If a violating operation

> attempts to write more than one element of a bounded queue, any

> element with index less than or equal to the bound shall be written

> exactly as it would be if the queue were unbounded.? Perhaps an

> example would help.



I guess the "if more than one element" phrase is strictly redundant,

but the rule is applicable only to operations that write

more than one element.  In the same example as above, I want



  Q2 = {0,1,2,3};



to write elements as follows:



  Q2[0] = 0; Q2[1] = 1;



just as it would have done if Q2 were unbounded, even though

the operation AS A WHOLE violates the queue's bound.  Would you

be OK with addition of that example?

[Alsop, Thomas R] I think I get it now with the example.  You want to clarify that a write to a bounded queue succeeds for the range of the bound that is legal and fails with a warning for the range that is out of bounds, right? Now that I have that clarity, I can read the sentence again and it makes sense what you are trying to say.



How bout this rewording:



"If a write operation to a bounded queue has elements both inside and outside the bound of the queue, the elements writing inside the bound shall succeed, while the elements outside the bound shall be ignored and the implementation shall issue a warning."



I'll prepare a modified proposal with these two changes

(Tools=>Implementations, added example) in the hope that

EC can treat it as a friendly amendment next week.





-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Apr 29 10:27:03 2009

This archive was generated by hypermail 2.1.8 : Wed Apr 29 2009 - 10:27:15 PDT