> Shabtay,
> 
> A bit overdue but here are some reponses to your issues.
[Shabtay] Thanks. This was not the most urgent issue.
> johnS:
> This is most likely a matter of clarification. In intent of an info 
> message is that it is a warning or purely informational and should not 
> have the effect of aborting a simulation.
> 
> I would suggest the following re-wording after this paragraph:
> 
> Existing paragraph in section 5.3.2:
> 
> "This method registers an optional info handler with the SCE-MI that 
> is called when a warning or informational status message occurs."
> 
> Added immediately after:
> 
> "This method must only be used for message reporting or logging 
> purposes and must not abort the simulation. Only SceMiEC error 
> handlers are reserved for that purpose."
[Shabtay] I agree that this is a matter of clarification and the proposed wording addresses that. 
PS. I see this in section 5.3.2.2 though.
> 
> >
> > A second order of magnitude issue is that categorization of what is 
> > considered a SceMiError (aka fatal error) and what is considered 
> > Info, warning and NonFatal error is also left to the implementation.
> 
> johnS:
> I think the combination of my added paragraph above combined with the 
> last paragraph in the section should make these clear. This last 
> paragraph states,
> 
> "An additional category, called SceMiNonFatalError, can be used to log 
> all error conditions leading up to a fatal error. The final fatal 
> error message shall always be logged using a SceMiEC structure and 
> SceMiErrorHandler function so an abort sequence is properly handled 
> (see 5.3.2.1). In addition, the info message can optionally be tagged 
> with a unique identifying integer specified in the Id field."
[Shabtay] Yep, but in section 5.3.2.2 I believe. Am I using the correct version?
> 
> Perhaps we can also add something to section 5.3.2.1 that states that 
> is expected that user defined SceMiEC error handlers or user level 
> code reacting to a returned SceMiEC status indicating a fatal error 
> are expected to initiate an abort operation in a manner that is 
> properly suited to the application.
[Shabtay] On this one, I don't see an added value of adding that as the spec already defines SceMiEC errors as irrecoverable errors. 

I think however that we still need to table the fact that SCE-MI does not explicitly define categorization for errors and info types in the sense that one implementation may return a SceMiEC error when another one may just return a warning. I don't think that this will be common the decision which type to use or which level of warning to provide is mostly a matter of common sense.

Creating consistency among different implementation in this regards is quite a task and I am not sure that this is at such a priority level that we should do more than noting that. We could decide to address issues surgically if this becomes an issue.

I am OK is we close IM25 based on your first proposed clarification. 

========================================================================================================
Original issue


The SceMiEC *ec argument allows the caller of any SCE-MI class to determine if
errors will be conveyed to the caller by using the non-NULL pointer or to an
error handler by using the NULL pointer (either the default error handler or
the one that was registered). 

However, if I properly understood section 5.3.2.2 that deals with the SceMiIC
class, info type messages cannot be controlled to go back to the caller and will
only be conveyed to an info handler, either the default error handler or the
one that was registered.

If I further look at which types of errors and information is provided in each
case, the error handling facility is stated to support "irrevocable errors" and
thus the non-Null pointer option is of little use as the application needs to
report the error and abort. 

To the contrary, as the info type messages should be handled at the discretion
of each caller, I would have expected that the caller would receive the info
type messages and thus the non-Null pointer option will be of higher value if
applied to info type messages. In particular this is useful given the 3
enumerations of info types that the caller may branch upon given the context
of the call.

Have I misunderstood the intended use of these classes? 

Can one explain the current logic behind providing the non-NULL pointer
option for irrevocable errors and not for info handling? Is this an issue
worth reconsidering for amending in the spec?


Shabtay