Report 2012 Actions
Problem Report Number |
2012 |
Submitter's Classification |
Specification problem |
State |
Resolved |
Resolution |
Permanent Interpretation (PIN) |
Problem Resolution ID |
PIN.X.0244 |
Raised |
1998-03-18 08:00 |
Updated |
2003-03-13 08:00 |
Published |
1998-05-06 08:00 |
Product Standard |
Transport Service XTI V2 |
Certification Program |
The Open Brand certification program |
Test Suite |
VST version 5.2.3 |
Test Identification |
unk/unk/xti.h unk |
Specification |
Networking Services Issue 5 |
Location in Spec |
See Problem Text |
Problem Summary |
PINT5.001 We have a difference of interpretation of the following normative definition of legacy from XNS5 chapter 1 , section 1.1 Terminology: "legacy Certain features are legacy, which means that they are bei... |
Problem Text |
We have a difference of interpretation of the following normative definition of legacy from XNS5 chapter 1 , section 1.1 Terminology: "legacy Certain features are legacy, which means that they are being retained for compatibility with older applications, but have limitations which make them inappropriate for developing portable applications. New applications should use alternative means of obtaining equivalent functionality. Legacy features are marked LEGACY."
This wording is also used in appendix F when describing the xti.h header contents.
We interpret this wording to mean that the LEGACY symbols are "retained only when _XOPEN_SOURCE < 500". The test suite assumes they are also "retained when _XOPEN_SOURCE == 500".
Can an application assume that the symbols in xti.h marked LEGACY are visible when _XOPEN_SOURCE == 500 ?
|
Test Output |
Not applicable, this is a request for interpretation of the specification.
|
Review Information
Review Type |
TSMA Review |
Start Date |
null |
Completed |
null |
Status |
Complete |
Review Recommendation |
No Resolution Given |
Review Response |
The suggested interpretation seems to conflict with the following text from section 1.3:
"Applications should ensure that the feature test macro _XOPEN_SOURCE is defined with the value 500 before inclusion of any header. This is needed to enable the functionality described in this document"
If the intention was for the legacy symbols not to be visible when _XOPEN_SOURCE is 500 then they should not appear in the spec at all. (At least not in the normative text; they could be mentioned in some historical commentary or advice to application writers.)
If the legacy symbols are not required to be visible in <xti.h> on XNS5 implementations this would create a major portability problem for XNS4 applications to systems which only implement XNS5. There may not be any such systems initially, as XNS5 is presumably being implemented first on systems that already implement XNS4, but the problem should not be ignored just because it may be some time before it will be encountered.
There is also the possibility that application writers may wish to update their XNS4 applications to take advantage of some features of XNS5 where they are available (e.g. the scatter-gather send/receive functions). In order to use these features the application would have to be compiled with _XOPEN_SOURCE=500. If this meant that the legacy symbols would no longer be visible in <xti.h>, then this would generate additional work to be done as part of the update that would otherwise be unnecessary.
We believe the specification is clear that the legacy symbols must be visible in <xti.h> when _XOPEN_SOURCE is 500. However, since this issue is already the subject of debate on the XNET working group, this interpretation request should be forwarded to them for review.
|
Review Type |
SA Review |
Start Date |
null |
Completed |
null |
Status |
Complete |
Review Resolution |
No Resolution Given |
Review Conclusion |
This request should go for a 14 day review.
|
Review Type |
Expert Group Review |
Start Date |
null |
Completed |
null |
Status |
Complete |
Review Resolution |
No Resolution Given |
Review Conclusion |
RESOLUTION XNET53-1
XNET has considered a number of issues relating to the behaviour of various headers under different values of _XOPEN_SOURCE. XNET resolves to produce detailed change requests in the form of corrigenda which will give effect to the following decisions in XNS Issue 5.
1. Any text that relates to behaviour of the implementation when _XOPEN_SOURCE is less than 500 is informative, not normative. This behaviour is specified normatively in earlier issues of XNS.
2. Conformant systems are not required to provide the OPT_NEXTHDR macro.
3. Protocol-specific symbols defined in <xti_inet.h> or <xti_osi.h> are not required to be available when <xti.h> is included by the application but <xti_inet.h> or <xti_osi.h> (respectively) is not included by the application. : 4. An implementation is only required to provide protocol-specific headers for those protocols that it supports.
5. An implementation need not make available symbols marked in XNS5 as "LEGACY".
6. Although identifiers marked as "LEGACY" are not specified as being reserved for any use by the implementation, implementations may make them available.
XNET is aware that this may mean that XNS5 applications will have to be changed if they are to remain portable, but XNET believes that few, if any, such applications have yet been written, that these changes are necessary, and that they should therefore be made now.
In view of 4. and 5. above.
A Permanent Interpretation is recommended.
|
Review Type |
SA Review |
Start Date |
null |
Completed |
null |
Status |
Complete |
Review Resolution |
Permanent Interpretation (PIN) |
Review Conclusion |
A Permanent Interpretation is granted.
|
Problem Reporting System Options:
|