Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!psuvax1!rutgers!rochester!kodak!uupsi!sunic!fuug!funic!santra!santra!sja
From: sja@sirius.hut.fi (Sakari Jalovaara)
Newsgroups: comp.lang.c
Subject: Re: Managing error strings in C
Message-ID: <1991Jan19.181522.23871@santra.uucp>
Date: 19 Jan 91 19:14:51 GMT
References: <1991Jan10.122227@lotus.lotus.com> <620@necssd.NEC.COM> <1991Jan19.163652.9203@hemel.bull.co.uk>
Sender: news@santra.uucp (Cnews - USENET news system)
Organization: Helsinki University of Technology
Lines: 48
In-Reply-To: boyce@hemel.bull.co.uk's message of 19 Jan 91 16:36:52 GMT

> a) "Error %{1}d on line %{2}d" and b)  "Line %{2}d: error %{1}d detected"

Pretty much the tracks I was thinking along - except that the type of
the object (here "d" for "int") being printed does not really belong
in the message format string: if a user can customize his own messages
imagine what happens with

	"Line %{2}s: error %{1}f detected"
		  ^ oops       ^ oops

A program should not crash if it is given bad input and a user should
not need to know things like the types used internally in a program.
Here is how I thought an error text might be printed:

	message (HELLO_WORLD, (char *) 0);
	message (ERROR_ON_LINE,
			/* error name / type / argument */
			"line",         "d",   line_number,
			"error",        "s",   error_text,
			(char *) 0);

and the error text database would look something like

	HELLO_WORLD Hello, world!
	ERROR_ON_LINE Error {error} on line {line}

with automatically generated indexes in the beginning of the file for
faster access.

Implementing that is left as an exercise for the reader.

(Even that isn't enough if you want really fancy messages - how can
you pluralize words or determine if you need "a" or "an" articles etc.
For a multi-lingual system doing that takes separate binaries for
different human languages or writing the message system in an
interpreted language.  Yuck.)

***

The MIT Athena project has some kind of an error reporting tool that
takes specifications like

	ec ZERR_AUTHFAIL, "Server could not verify authentication"

and turns them to .c and .h files (the messages are compiled in in the
a.out.)  It is called "et" and is distributed at least as a part of
Zephyr (ftp athena-dist.mit.edu).  I haven't tried it.
									++sja