gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/08/88)
In article <1731@edison.GE.COM> rja@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.