Xref: utzoo comp.unix.questions:10549 comp.lang.c:14590
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!ge-dab!ge-rtp!edison!rja
From: rja@edison.GE.COM (rja)
Newsgroups: comp.unix.questions,comp.lang.c
Subject: Re: System 5.3.1 signal() replacement?
Summary: say again
Message-ID: <1731@edison.GE.COM>
Date: 6 Dec 88 01:08:05 GMT
References: <7997@dasys1.UUCP> <2914@arcturus> <9055@smoke.BRL.MIL>
Organization: GE-Fanuc North America
Lines: 19

In article <9055@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
> ANSI C will specify signal() and minimal associated semantics for it,
> just enough for applications to have a "fighting chance" at portable
> use of signals.  Technically there are loopholes big enough to drive
> an M1A1 through, but it is to be hoped that most implementations will
> strive to provide usable signal facilities.  POSIX (IEEE Std 1003.1)
> specifies a different interface that is considerably more robust, so
> if you need to do much more than trap SIGINT to set an "interrupt
> requested" shared flag (of type "volatile sig_atomic_t"), you're
> advised to use the POSIX facilities instead of signal().

I am unclear about the part above where it seems to state that the
IEEE 1003.1 POSIX standard and ANSI C standard are in conflict.
I keep reading in IEEE Computer and the earlier published 1003.1 draft
that they were coordinating their effort with the X3J11 effort to make
sure the 2 were compatible.

Ran
rja@edison.ge.com