Re: [Plib-devel] error message routines

[Steve B. <sjb...@ai...>]

> Dave McClurg wrote:
> 
> Here is the revised spec based on Steve's comments:

Thanks.  That seems much better.

> enum xxxSeverity
> {
>   XXX_DEBUG,    // Messages that can safely be ignored.
>   XXX_WARNING,  // Messages that are important.
>   XXX_FATAL,    // Errors that we cannot recover from.
> } ;
> 
> void xxxInit ( void ) ; //for now, just calls xxxClearError()
> 
> void xxxSetError ( int severity, const char *fmt, ... ) ;
> char* xxxGetError ( void ) ;
> void xxxClearError ( void ) ;
> 
> typedef void (*xxxErrorCallback)( char* ) ;
> xxxErrorCallback xxxGetErrorCallback ( void ) ;
> void xxxSetErrorCallback ( xxxErrorCallback cb ) ;
> 
> -----
> 
> The default error callback will print the
> message to stderr.  if ( severity == XXX_FATAL )
> should the default callback exit(1) the app?

Since we say that these are unrecoverable, we certainly
need to terminate the program after the error callback
has been called.

It should probably abort() to generate a core file...
but to a degree it doesn't matter what we do since
the application can clearly override the default
behavior by either calling exit(1) or abort(TRUE)
in his own error callback.

 
> This will be something general to all of PLIB -
> including PUI, SL, etc.  As a general library,
> the application might like to handle it's own
> errors the same way.

Yes.
 
> What should the new library be called (xxx)?
> Could we later add some endian support code,
> a plib version string, and a couple basic types?
> If so, a more general name than err would be
> appropriate.  How about...
> 
>         ul - utility library
> 
> Note: This adds a dependency to all the other
> PLIB libraries.

That all seems pretty reasonable.

There are a bunch of routines that could usefully
be placed there.

> Should I proceed?

Yes - if we are agreed that we want this in 1.2.

The main problem with this is that we'll cause
applications to have to amend their linker
command to include '-lplibul'.

That says to me that if we want this, we should
put out a final PLIB 1.1.xx release for testing
before 1.2.0 becomes the stable standard.

One way to avoid that is to make those few
simple routines fit into a header file as
'inline's - then there is no change to the
linker requirements in 1.2 - and we can
turn it into a fullscale library in 1.3.

Since none of those routines is likely to
be more than one or two lines, and existing
applications would continue to work without
including <plib/ul.h> - this would be more
acceptable to application authors I guess.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)