Date: Mon, 2 Feb 1998 18:59:01 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Nate Eldredge <eldredge AT ap DOT net>
cc: DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Subject: Re: NSIG ?
In-Reply-To: <199802020241.SAA15976@adit.ap.net>
Message-ID: <Pine.SUN.3.91.980202185733.19322G-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Sun, 1 Feb 1998, Nate Eldredge wrote:

> 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.

Linux is just one case of Unix-like systems.  The names I used come
from other, similarly ``standard'' cases.  I don't see any way to
decide which one is ``better''.

> Sorry to nullify others' work

You can always submit a patch when that work gets into the next
release ;-).  After all, that's what alphas are for.

> but I'm so used to seeing things like "Segmentation fault" that
> anything else sort of grates.

I sincerely hope you don't see ``Segmentation fault'' too much ;-).

Seriously though, I think there might be a misunderstanding here.
These are NOT the descriptions printed by the default signal handler
when it aborts the program.  Under what circumstances did you see the
names you quoted?  The DJGPP port of GNU Make, for example, uses the
names I submitted.

> * 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.

I looked at several Unix varieties and also in application programs
that use this list (Emacs and GNU Make), and saw `sys_siglist' in all
of them.  Perhaps we can define both to be aliases for the same list?

> * 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.

I think I tried this, but it would not compile under the restrictive
set of switches used by the libc build procedure (due to the conflict
between `char *' and `const char *').  I have nothing against a
solution to this problem, if one can be found and is okay with DJ.
Either way, these are only 200-odd bytes we are talking about...