🚀 go-pugleaf

Submitted-by: mckean@xopen.co.uk (Roy Max McKean)

Firstly, thanks to David Rowley and Dave Decot who have given
their answers to the questions Glenn Hoogerwerf posed.  Here are
my answers, which I hope are also helpful:  I believe I have
answered from an honest "X/Open" viewpoint, but please remember
that X/Open is a consensus organisation, and the following is my
personal interpretation, not an official response!  (If anyone
needs an official answer to a particular question, lease let me
know, and I will ensure that one is provided!)

Secondly, to try to answer the questions:

To conform to any XPGn specification, implementations MUST provide
all interfaces marked "TO BE WITHDRAWN" (unless there is some
other marking which makes the interface optional).  This may seem
irritating for those who are working on "new" XPG implementations,
but it is wrong to call them "dead" interfaces:  there are a lot
of applications out there written for XPG3 which may rely on the
presence of these interfaces, and XPG4 implementation vendors are
obliged to provide a good migration path for those applications.  
(It amuses me that in this sense even XPG3 is now a legacy system!)

Application writers should be able to port their XPG3 applications
immediately and simply to XPG4 implementations, then (during the
lifetime of XPG4) clean out the TBW dependencies as to make the
applications ready to port to XPG5 implementations as soon as they
are available.

This is why the X/Open Working Groups responsible for writing the
specifications do everything possible to put interfaces which are
being superseded through the TBW status, rather than just dumping
them.

Regarding the specific interfaces mentioned:

cc      is needed for the reasons above.  Note that the ability to
	COMPILE X/Open C as well as ISO C is ALSO required for
	XPG4 implementations.  (The implementation may implement
	this by using a different compiler from that invoked by
	c89, but the compiled code from the two types of source
	must interwork properly).

dis 	is also marked as OPTIONAL anyway, reflecting the
	difficulty of providing the function in a truly useful
	portable fashion, so implementers need not provide it, and
	application writers should not rely on it for maximum
	portability.

lint 	is part of the DEVELOPMENT option, so need not be provided
	on ALL conforming implementations, only those which do
	claim conformance to that option.
                
Please note that at the beginning of my message I chose my words
carefully:  I have described the requirements to conform to the
SPECIFICATIONS.  David Rowley is correct to point out that the
conformance requirements for the initial release of the XPG4
Commands and Utilities COMPONENT will be relatively relaxed:  
the major requirement being that the implementor documents the
differences from the "expected" behaviour.

This particular specification has been greatly extended since XPG3:  
it has been aligned with ISO/IEC DIS 9945-2:1992, so it includes
everything in POSIX.2 and POSIX.2a!  There will initially be a
large number of applications which may depend on XPG3 behaviour,
so during an introductory period, in the area of Commands and
Utilities, we are allowing the vendors of branded systems to
choose what migration path to offer their customers.

When there are enough applications which can run in, and enough
vendors able to provide, fully conformant XPG4 Commands and
Utilities Components, the definition will be updated to include
far more stringent conformance requirements.


Thirdly, (with apologies if these seems like an advertisement) these 
issues have now been clarified in the FINAL VERSIONS of the documents 
which can now be ordered from the X/Open Publications Department:

  PO Box 109, Penn, High Wycombe, Bucks, HP10 8NP, England 
  Tel: +44 494 813 844        Fax: +44 494 814 989

The documents in question are:

  X/Open CAE Specification C202 (System Interfaces and Headers, Issue 4)
  X/Open CAE Specification C203 (Commands and Utilities, Issue 4)
  X/Open CAE Specification C204 (System Interface Definitions, Issue 4)

You can also now order the first issue of the "parent" document,
  X/Open XPG4 Documentation X924 (X/Open Systems and Branded Products: XPG4)
(either as a whole or just the pieces you need) and the Base Migration Guide:
  X/Open Guide G204 (XPG3-XPG4 Base Migration Guide).

(The parent document is the binder which explains the whole
structure of the XPG4 product, and contains the Component
Definitions, Profiles, Guide to Branding, the TMLA, CSQs, and 
the lists of Branded Products and X/ Open publications)

If you have any questions about these or any other X/Open 
publications, please ask Karen Johnson to help.  
(<k.johnson@xopen.co.uk> Phone as below, ext 2229)

Kind Regards, 

Roy McKean.

                -------------------------------------
 Roy "Max" McKean, Development Manager  Tel: +44 734 508 311 ext 2271
 X/Open Company Limited                 Fax:          +44 734 500 110
 Apex Plaza, Forbury Road               EMail:   r.mckean@xopen.co.uk
 Reading, England, RG1 1AX              Home:         +44 734 403 506
                --------------------------------------





Volume-Number: Volume 28, Number 95