P1003/X3J11 liaison (was: System 5.3.1 signal() replacement?)

[Doug Gwyn]

In article <1731 at edison.GE.COM> rja at edison.GE.COM (rja) writes:
>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.

POSIX specifies a different interface than ANSI C (as I said).
What's "in conflict" about that?

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

Well, the coordination wasn't all that great for a variety of reasons,
including simultaneous meetings in different locations, the fading away
of the original X3J11/P1003 liaison agent, and the inability of the new
acting liaison (me) to attend both groups' meetings, but nonetheless it
is believed that the two standards have no area of disagreement that
would preclude an implementation from simultaneously conforming to both.

In fact, there were several accommodations on both sides in an attempt
to make these complementary standards compatible.  For example, since
we were discussing signal(), I managed to talk X3J11 into allowing
signal blocking upon entry to a signal handler as an alternative to the
traditional reset to SIG_DFL, so that signal() could be implemented
more reasonably in a POSIX-conforming ("reliable signals") environment.

P1003 adjusted their use of standard headers to conform to the strict
X3J11 injunction against name space pollution by implementations, and
earlier they had left out the third (environment array) argument to
main(), because at the time we thought that X3J11 had prohibited other
than 0 or 2 arguments to main().  (Current X3J11 consensus seems to be
that 3 arguments is an allowed extension.)  The alternate use of a
global "environ" variable was ALMOST a genuine conflict with ANSI C,
but a couple of technical solutions for conforming implementation have
been figured out, so it isn't insoluble.  It IS unfortunate that the
"environ" issue was raised so late in the process; earlier we may have
been able to work out a better compromise solution.  For example, I
would have recommended a set of environment-access functions in place
of using a global array pointer and known string formats.  In fact,
this is still a good idea, although not in any standard.  Maybe I'll
publish a public-domain package for this, much like the directory-
access package.