std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/09/85)
This is the first of a series of articles consisting mostly of mail
items from Robert Elz about P1003 Draft 4. They have all been given to
the appropriate section reviewers on the P1003 committee and will be
taken into account during the Trial Use balloting process. They are
interspersed here with comments by Doug Gwyn (marked -Gwyn) which
arrived by mail after Draft 5 was available but before the Dallas
Steering Group meeting. Comments from Don Kretsch (marked -Kretsch)
were collected at the Dallas meeting. I have added some more (marked
-jsq) while preparing these articles for posting. All the latter three
people are members of the P1003 working group. Don Kretsch is also a
member of X3J11 and is the main liaison between the two committees.
The usual disclaimer applies: nothing posted in this newsgroup
by a committee member necessarily represents the official
position of IEEE, P1003, or any other organization.
Submissions do not ordinarily sit around for a month before
appearing in the newsgroup. The original poster explicitly
requested that responses be collected and posted with his originals.
The comments on the original remarks are not necessarily definitive,
and the set of people who made them is pretty arbitrary.
Further responses are solicited.
Date: 06 Oct 85 19:26:29 +1000 (Sun)
Subject: Is SIGILL omitted from the list of "hardware" signals for good reason?
>From: Robert Elz <munnari!kre@seismo.CSS.GOV>
In P1003/D4, section 3.3.2 (Signal Processing), there are several
mentions to a list of distinguished signals, being
SIGTRAP SIGIOT SIGEMT SIGFPE SIGBUS and SIGSEGV
These are the signals to which non-recoverable hardware errors
should be mapped, the action taken upon return from a signal
handler after one of these signals is undefined, and SIGABRT
is to be mapped to one of these.
I note the absense of SIGILL from this list, and wonder why?
Was this deliberately omitted - in which case I object, as
a SIGILL is quite likely the best choice for SIGABRT, and it
certainly may be undefined what will happen upon return
from a SIGILL signal handler. Or is this a mere oversight?
[ SIGILL was added for Draft 5. For some reason, Draft 5
still does not permit SIGABRT to be defined as SIGILL; I
don't understand why not. I thought it was going to be
allowed; only SIGFPE should be disallowed as SIGABRT. -Gwyn ]
Robert Elz seismo!munnari!kre kre%munnari.oz@seismo.css.gov
Volume-Number: Volume 3, Number 5std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/14/85)
Date: Sun, 10 Nov 85 16:04:35 PST From: mordor!lll-crg!sun!guy (Guy Harris) > Was this deliberately omitted - in which case I object, as > a SIGILL is quite likely the best choice for SIGABRT... Not necessarily; 4.xBSD happened to choose it for the VAX, because there's no IOT instruction, but VAX S5's "abort" routine is a (portable!) piece of C code which does kill(getpid(), SIGIOT); (and also flushes all the Standard I/O buffers beforehand). SIGIOT is pretty useless except on PDP-11s; the S5 shell says "abort - core dumped" rather than "IOT trap - core dumped" when a process gets a SIGIOT. I think 4.xBSD should adopt S5's "abort" routine. Volume-Number: Volume 3, Number 12