Date: Sun, 1 Feb 1998 18:41:07 -0800 (PST) Message-Id: <199802020241.SAA15976@adit.ap.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Eli Zaretskii , DJ Delorie From: Nate Eldredge Subject: Re: NSIG ? Cc: djgpp-workers AT delorie DOT com Precedence: bulk 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