I had previously proposed to change the prototypes for the 
RegisterErrorHandler() and RegisterInfoHandler() methods 
as follows: 

  static SceMiErrorHandler 
  SceMi::RegisterErrorHandler( 
    SceMiErrorHandler errorHandler, 
    void *context); 


  static SceMiInfoHandler 
  SceMi::RegisterInfoHandler( 
    SceMiInfoHandler infoHandler, 
    void *context); 

The difference between these and the current standard is that 
the new ones return the previous error/info handler so that 
it can be restored later similar to how the UNIX signal() 
call works for signal handlers. 

However, I have since realized that the above is flawed because 
it neglects to take into account that you also need to restore 
the original context argument. One way to fix is to use 
std::pair: 

  static std::pair<SceMiErrorHandler, void *> 
  SceMi::RegisterErrorHandler( 
    SceMiErrorHandler errorHandler, 
    void *context); 

but this does not port to the C API. Another possibility is 
to define a struct: 

  struct SceMiErrorHandlerContext 
  { 
    SceMiErrorHandler Handler; 
    void *Context; 
  }; 

  static SceMiErrorHandlerContext 
  SceMi::RegisterErrorHandler( 
    SceMiErrorHandler errorHandler, 
    void *context); 

This will work in both C and C++ but people may object to 
returning a struct . . . This shouldn't be a problem, though 
as the struct is very small: two pointer values, i.e., 8 
bytes on a 32-bit architecture or 16 bytes on a 64-bit 
architecture. 

Per

=======================================================


> Actually this is not a bad idea and I think it can be changed 
> while keeping existing code compatible. We can have 
> RegisterError/InfoHandler() return the previous setting. 

Ok, let's do :-) So the new prototypes shall be: 

  static SceMiErrorHandler 
  SceMi::RegisterErrorHandler( 
    SceMiErrorHandler errorHandler, 
    void *context); 

  static SceMiInfoHandler 
  SceMi::RegisterInfoHandler( 
    SceMiInfoHandler infoHandler, 
    void *context); 

Add the following sentence to the sentence below each prototype in 
the spec: 

  If the errorHandler argument is NULL, the default error handler 
  will be registered. A pointer to the previous error handler is 
  returned. If the previous error handler is the default error 
  handler, NULL will be returned. 

  If the infoHandler argument is NULL, the default info handler 
  will be registered. A pointer to the previous info handler is 
  returned. If the previous info handler is the default info 
  handler, NULL will be returned. 

I added the handling of NULL because it occurred to me that the 
spec did not deal with this. 

> Library/IP code will want to deal with control flow of 
> recoverable errors but don't you think users themselves 
> will ultimately want control of how fatal errors 
> are handled ? 

Yes, of course. I was talking about recoverable errors, 
or at least trying to :-) 

> I'm probably still missing what you're trying to get 
> at however when you speak of IP libraries and error 
> handling. 

I was thinking of a scenario where some shared code on the 
software side could adapt to a family of BFMs that are similar 
but still have varying internal organization such as number 
and type of ports. If Bind*Port() reports recoverable errors 
via the info mechanism and this adaptive code needs to know 
whether Bind*Port() failed because the transactor itself is 
not in the netlist or a port within it was not present, then 
the code would have to register its own info handler while 
calling Bind*Port() and look at the info codes returned and 
hope that these are distinct for each recoverable error 
and, better yet, standardized. The change to 
RegisterInfoHandler() would be half of the solution.