Date: Mon, 2 Feb 1998 21:20:40 -0800 (PST)
Message-Id: <199802030520.VAA07634@adit.ap.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From: Nate Eldredge <eldredge AT ap DOT net>
Subject: Re: NSIG ?
Cc: DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Precedence: bulk

At 06:59  2/2/1998 +0200, Eli Zaretskii wrote:
>
>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''.
Ah, okay. I'm just provincial, I guess; I'd never seen anything else and
assumed Linux's were standard.
>
>> 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.
That actually won't be necessary. I somehow thought that your names had just
been invented by you, and I thought standard ones were better. But since
yours actually are standard, I won't argue.
>
>> 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 haven't actually seen them on DJGPP. It of course says "Exiting due to
SIGSEGV...", without using the descriptive name at all (unless this has
changed for 2.02, which I don't have). I meant I see them on Unix when
something crashes (which, yes, is infrequent). 
>
>> * 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?
You are right, I think I am confused. But the aliased version wouldn't be a
bad idea, IMHO.
>
>> * 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.
Can't we declare `const char *sys_siglist[]' and `const char
unknown_signal[]'? Wouldn't that fix it? Or am I missing something really
obvious? (Wouldn't it be a good idea to declare `sys_siglist' `const' anyway?)
>Either way, these are only 200-odd bytes we are talking about...
True, it's hardly worth thinking too hard about.

Nate Eldredge
eldredge AT ap DOT net