| |
Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • ShopThe Open Brand -- Problem Reporting and Interpretations System |
|
Problem Report 1160 Details
Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges
This page provides all information on Problem Report 1160.
Report 1160 Actions
Problem Report Number 1160 Submitter's Classification Test Suite problem State Resolved Resolution Rejected (REJ) Problem Resolution ID REJ.X.0362 Raised 1970-01-01 08:00 Updated 2003-03-13 08:00 Published null Product Standard Commands and Utilities V2 (UNIX 95) Certification Program The Open Brand certification program Test Suite VSU version 4.1.1 Test Identification CAPIutil/c89 3 Problem Summary PG4U.00108 The IR claims that the appropriate headers must be included to use a function. Problem Text
The testcase c89 #3 fails due to incorrect assumption in the testcase that
the operand "-l xnet" would make visible all the xnet library functions
even though the corresponding header files are not included.
X/Open CAE Specification, Networking Services, Issue 4, section 1.3 only describes
-l xnet If the implementation defines _XOPEN_UNIX, this operand makes visible
all the functions referenced in this document. An implementation may
search this library in the absence of this operand.
and in section 1.3.2, it states:
The set of identifiers visible to the application consists
of precisely those identifiers from the header pages of the
included headers, as well as additional identifiers reserved
for the implementation.
The above testcase (C89 #3) does not consider the specification of bind(),connect(),
listen(),sendto(), recvmsg() etc. (see chpater 8 ) where it clearly states the
usage of the function.
For example, in case of bind(), it states:
SYNOPSIS
#include<sys/socket.h>
int bind(int socket, const struct sockaddr *address, size_t address_len);
The test does not include any of the header files which are required according
to the specification and thus should not expect "-l xnet" to make all the xnet
library functions visible.
We request that the waiver be granted for this test failure because of the test
suite deficiency.
Further information as an appeal against initial refusal
--------------------------------------------------------
We would like to appeal the response to waiver PG4U.00108 against
CAPIutil/c89 test #3 as it relates to the bind(), sendmsg(),
recvmsg(), sendto(), connect() and listen() functions.
The consultant's response states that the request was refused for
the following reason:
"Section 2.1 in the XSH states that
Provided that a library function can be declared
without reference to any type defined in a header,
it is also permissible to declare the function, either
explicitly or implicitly, and use it without including
its associated header."
We believe the rationale for the denial is invalid. In context to
the socket interface, the XNS specification should be consulted and
not the XSH spec. Although the same text appears in the printed
version of the XNS spec in section 1.2, the paragraph is invalidated
by an approved CR which can found in archives of XoXTI-787.
While all the arguments brought forward in the XoXTI-787 CR refer
to XTI, the same arguments do in fact apply to sockets as well.
For instance, some implementations have to provide some form of
backward compatibility to the socket interface as implemented in
4.3BSD tahoe. This interface is different e.g. in that there were no
msg_control, msg_controllen, and msg_flags field in the msghdr
structure.
In any case, the text changed by the XoXTI-787 CR is in section 1.2
which is common for both sockets and XTI.
XoXTI-787 CR states the following in reference to above mentioned
XNS, issue 4, section 1.2 :
" This language should be eliminated for the following reasons:
1. It appears to contradict the last paragraph of 1.2, where
application writers are required to include at least the
required headers.
3. Test cases that enforce this new requirement must not be
used to brand XTI implementations for XTI branding.
4. The wording prevents vendors from supporting multiple ABI's
where the semantics of new functions conflict with older
functions."
The approved change due to the above CR recommends removal of text
in XNS section 1.2 beginning with
"Any functions declared in a header may also be...."
up to the text and the end of page 2 which ends with:
"... the behavior is undefined."
This CR also changes the text to allow the redefinition of a function name
to another function name for backward compatibility.
Please refer to XoTGnet meeting minutes archive for XNET-37 at Tokyo
section 4.9.5, action 37-29 for further details.
Furthermore, besides the approved changes in XNS, the X/Open consultants'
argument does not apply because none of these functions except listen() can
be declared without reference to a type defined in a header as per XNS
synopsis for bind(), sendmsg(), recvmsg(), sendto(), connect() functions.
The bind(), sendto() and connect() functions require the "struct sockaddr"
type defined in <sys/socket.h>. The sendmsg() and recvmsg() functions require
the "struct msghdr" type defined in <sys/socket.h>.
We urge the consultants to refer to XNS, Issue 4 in this context
and request that this appeal be reviewed by the XoTGnet group.Test Output
TEST CASE: c89
TEST PURPOSE #3
The command c89 when the -l xnet operand is used and
_XOPEN_SOURCE_EXTENDED is defined by the application
shall make visible all sockets functions listed in the
XNI.
TEST: File referencing all functions built successfully
ERROR: Unsatisfied references:
Undefined first referenced
symbol in file
bind test3.o
sendmsg test3.o
recvmsg test3.o
sendto test3.o
listen test3.o
connect test3.o
ld: fatal: Symbol referencing errors. No output written to test3
3 FAIL
Review Information
Review Type TSMA Review Start Date null Completed null Status Complete Review Recommendation No Resolution Given Review Response
We recommend this request be refused.
Section 2.1 in the XSH states that
Provided that a library function can be declared
without reference to any type defined in a header, it
is also permissible to declare the function, either
explicitly or implicitly, and use it without including
its associated header.
The tests referred to here all use their own function prototypes.
In these prototypes, no type defined in the header is referenced
(the functions are declared void), so the declarations should be
valid, and the function references should be resolved.
What the tests do is create programs with an unresolved symbol for the
name of each function which must be made visible, and then ensure the symbols
are resolved when JUST the -l xnet flag is used. Any errors c89 emits
in doing this are considered test failures. The resultant executable is
never run, so the actual library implementation is never invoked. Only
the ability to compile code referenceing these function with the
specificed c89 options is tested.
The files used look like:
void bind(void);
. . .
int main(char argc, char * const argv[])
{
void (*func)(void);
func = (void (*)(void)) bind;
}
Types, prototypes, implementation variations, etc. are not material here
as all that is being is done is to force a symbol reference for resolution
against the library. As such there is no dependency on the implementation's
headers nor any need to include them. Note, BTW, that if we did include
them so many other symbols would be drawn in that the tests would need
to use -l c to ensure everything got resolved, which would invalidate
the test by allowing -l c to make these symbols visible rather than -l xnet.
Review Type SA Review Start Date null Completed null Status Complete Review Resolution No Resolution Given Review Conclusion
The sockets chapters and the introductory matter in chapter one,
introduced in the X/Open Networking Services, Issue 4 , were
meant to be a component of the Single UNIX Specification, and hence
the requirements of XSH in this respect were intentional.
In the light of the XTI related CR, this should be sent for
review, with the recommendation that this be refused.
Review Type Expert Group Review Start Date null Completed null Status Complete Review Resolution No Resolution Given Review Conclusion
The waiver request asks that there be no requirement for function names
to be visible when -lxnet is specified but the associated header files are
not included.
A change that would remove this requirement has been approved
for Issue 5 of XNS but this change was not approved as a corrigendum to
Issue 4, on which the tests are based. It can not at this time be made a
corrigendum to Issue 4 without a formal resolution of XNET, approved by
the Technical Managers.
It has also been argued that the relevant clause in the specification does
not apply to functions whose declarations use types defined in the headers.
Whether the waiver should be granted on this ground is a matter for
interpretation. However, views expressed in XNET have been 2:1 against
granting the waiver, and this accords with the Consultant's Recommendation.
The interpretation must therefore be in the sense that the clause is
applicable and that the waiver should be refused.
Review Type SA Review Start Date null Completed null Status Complete Review Resolution Rejected (REJ) Review Conclusion
This request is refused.
Problem Reporting System Options:
- View Report 1160
- List All PRs
- Search Reports
- Email the System Administrator
- View the The Open Brand Interpretations Database User Manual
Contact the Certification Authority