Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: net.unix
Subject: Re: gripes about error reporting
Message-ID: <1900023@ccvaxa>
Date: Tue, 20-May-86 10:54:00 EDT
Article-I.D.: ccvaxa.1900023
Posted: Tue May 20 10:54:00 1986
Date-Received: Sun, 25-May-86 16:56:11 EDT
References: <406@houligan.UUCP>
Lines: 47
Nf-ID: #R:houligan.UUCP:406:ccvaxa:1900023:000:1857
Nf-From: ccvaxa.UUCP!aglew    May 20 09:54:00 1986


~> 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@gswd-vms