gripes about error reporting

[aglew at ccvaxa.UUCP]

~> Chris Torek's error() routine

I've been pushing a similar version of this routine that I call errorf()

    ERRORF(3)            UNIX Programmer's Manual             ERRORF(3)

    NAME
	 errorf - error message output routine

    SYNOPSIS
	 errorf(quit, format [, arg ] ...  )
	 int quit;
	 char *format;

    DESCRIPTION
	...

Pretty much the same, except that I never printed errno and the error
message - I left it up to the user to do that.  I did, however, provide a
function errnostr(errno) that returned a (char *) message like perror(),
suitable for embedding: 
	
    if( read(fd,buf,len) < 0 ) 
	errorf(-1,"%s trouble reading",errnostr(errno));

I have also nearly always found it useful to make the command line
parameters of a program into globals. I usually have Argc and Argv globals
set up in crt0.

I think that a good standard for error messages is a worthwhile idea. I am
certainly willing to accept Chris's error function, if it seems that it will
be accepted. However, as Chris remarks, the name `error()' is unfortunately
confusing - I think `errorf()' is a bit less confusing, and is agreeably
similar to `printf'.  I would also be strongly against adding more
parameters, like a FILE * for output stream - the beauty of it is being
short and simple, not very distracting. Providing the errno as an argument
is probably good, although I will continue to use errnostr for other reasons.

As for output redirection, may I suggest that the thing to do is to provide
a global pointer to an output function of your choice? I used this to
provide an easy way of directing output to a full screen menu display - a
lot easier than setting up a stream that behaved correctly on full screen
displays.

Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801    ARPAnet: aglew at gswd-vms