Re: New Feature Idea: Configurable text(msgs)

Perry Harrington (pedward@sun4.apsoft.com)
Tue, 17 Mar 1998 17:34:49 -0800 (PST)


The answer to this seems so obvious that it screams to me:

Just put all of your error messages in a header file. Then you
just use symbolic names for error messages.

Eg: (from a project I've worked on)

write_handle(handle,ERROR_552);

And in the header file I have:

#define UNKNOWN_COMMAND "500 Command unrecognized: \"%s\"\r\n" /* command */
#define QUITTING "221 %s signing off\r\n"
#define OK_RESPONSE "250 Ok\r\n"
#define GREETING "220 %s %s(%s #%s) PID %d ready %s\r\n"
#define HELP_STRING "214-Supported commands are:\r\n214 HELP NOOP MAIL RCPT DATA HELO QUIT\r\n"
#define LOOPING_MAIL "553 %s, eek, mail loops back to myself!\r\n"
#define AT_YOUR_SERVICE "250 %s at your service\r\n"
#define ALREADY_HELO "250 Gee, you already said hello, what is this, a party?\r\n"
#define DONT_LIKE_YOU "500 Off to see the Wizard huh, surely you must be mad!\r\n"
#define UNIMPLEMENTED "502 Command not implemented\r\n"
#define BAD_DELIM "501 Unbalanced delimiter in address\r\n"
#define MALFORMED_TEMP "501 Malformed address: %s\r\n"
#define MALFORMED_ADDR "501 Malformed address\r\n"
#define HOSTILE_ADDR "501 Address detected as hostile, rejected\r\n"
#define NO_RELAY "551 Relaying of mail via addresses not known to this system is prohibited\r\n"
#define ERROR_421 "421 %s Service not available, closing transmission channel\r\n"
#define BAD_SEQUENCE "503 Bad sequence of commands: %s\r\n"
#define SENDER_OK "250 %s, Sender ok\r\n"
#define RECIP_OK "250 %s, Recipient ok\r\n"
#define BAD_RECIP "550 %s, User Unknown\r\n"
#define ERROR_451 "451 Requested action aborted: local error in processing\r\n"
#define START_MAIL "354 Start mail input; end with <CRLF>.<CRLF>\r\n"
#define ERROR_552 "552 Requested mail action aborted: exceeded storage allocation\r\n"

This centralizes the error messages and allows for language portability.
Why does a slew of exotic solutions have to be introduced?

If you want to change error messages are runtime, I would suggest the following:

printf("%d: %s",ERROR_552,localized_errors[ERROR_552]);

You'd then have a header file like:

#define ERROR_552 129

const char *localized_errors[]={ ...
"552 Requested mail action aborted: exceeded storage allocation\r\n"
...
};

It's simple, it can be made into a global, static array that can be modified, and
it's portable.

--Perry

> It may be too late to fix this for Linux (just too much code) but I know
> that in some recent projects I've developed an error reporting mechanism
> that works similarly to VMS. The actual error string is coded in a certain
> format that can be translated to a human readable error message.
>
> If this is done for Linux, I could see something like:
>
> S:s:N:e
>
> Where S is the system or subsystem (KERNEL, DEVICE, MODULE, etc), s is a
> subsystem (or subsubsystem) (maybe for DEVICE the major:minor codes, etc), N
> is a location or place marker (for the project I'm working on, each function
> is numbered) and e is the actual error. I'm also able to include extra
> information (using a format string) along with the error. So, for example,
> the following error from exec_domain.c (2.0.32):
>
> printk(KERN_ERR "No execution domain for personality 0x%02lx\n",pers);
>
> would probably end up like:
>
> logerr(KERNEL,EXEC,__LINE__,ENODOMAIN,"x",pers);
>
> (for example). The output would probably look like:
>
> KERNEL:EXEC:00066:00234:0x34
>
> Ugly yes, but it would be possible to feed through a user space program
> for translation (I probably wouldn't use __LINE__, but associate a number
> for each function). It's compact and unambiguous and will probably never be
> adapted for Linux 8-)
>
> -spc (Remembers the last time this came up)
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>

-- 
Perry Harrington       Linux rules all OSes.    APSoft      ()
email: perry@apsoft.com 			Think Blue. /\

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu