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