Date:	Sun, 1 Feb 1998 18:41:07 -0800 (PST)
Message-Id:	<199802020241.SAA15976@adit.ap.net>
Mime-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, DJ Delorie <dj AT delorie DOT com>
From:	Nate Eldredge <eldredge AT ap DOT net>
Subject:	Re: NSIG ?
Cc:	djgpp-workers AT delorie DOT com

At 08:48  2/1/1998 +0200, Eli Zaretskii wrote:
>
>On Sun, 11 Jan 1998, DJ Delorie wrote:
>
>> > Should we add NSIG in v2.02?
>> 
>> Only if we're prepared to add _sys_siglist[] also.
>
>Here it is (together with a compatibility function `psignal' as desert).
[diff snipped]
I'd like to suggest that we make the descriptions similar to those usually
seen on Unix. Here are descriptions for signals that I took from
`strsignal.c' of libiberty (hope there aren't any copyright issues). They
are standard names, I always see them on Linux. I've included only the ones
that are different there.

For people of non-Unix background, the reason some are phrased in past tense
is that the most common use is to tell a user why (with what signal) their
program crashed.

Sorry to nullify others' work, but I'm so used to seeing things like
"Segmentation fault" that anything else sort of grates.

SIGABRT	  "Aborted"
SIGFPE	  "Arithmetic exception"
SIGSEGV	  "Segmentation fault"
SIGTERM	  "Terminated"
SIGKILL	  "Killed"
SIGPIPE	  "Broken pipe"
SIGPROF   "Profiling timer expired"

Also, some other suggestions.
* I believe it is more standard for the list to be called `_sys_siglist',
with a leading underscore. It is also less invasive of the user's namespace.
* Perhaps the entries of the list which all say "Unknown signal" should be
pointers to the single static string, rather than many `malloc'ed copies.
This would save time and memory, and nobody expects `sys_siglist' to be
writable anyway.

Nate Eldredge
eldredge AT ap DOT net

- Raw text -