Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 2006 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 2006.

Report 2006 Actions

    Problem Report Number 2006
    Submitter's Classification Specification problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0592
    Raised 1998-04-30 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Transport Service XTI
    Certification Program The Open Brand certification program
    Test Suite VST version 5.2.3
    Test Identification XTI.hdr/misc/xti 66
    Problem Summary PGT4R.021 This FIP occurs in the XPG4 mode of the test suite that is used for Unix95 branding, and this is not an issue in Unix98 mode. XNS Issue 4 specifies that following prototype for t_strerror() char *t_st...
    Problem Text
    This FIP occurs in the XPG4 mode of the test suite that is used for
    Unix95 branding, and this is not an issue in Unix98 mode.

    XNS Issue 4 specifies that following prototype for t_strerror()
    char *t_strerror(int errnum);
    XNS Issue 5 changed this to
    const char *t_strerror(int errnum);
    This was done in order to align with POSIX 1003.1g, and represents the
    right direction.

    Implementations conforming to XNS Issue 5 will automatically diverge from
    XNS Issue 4, and this represents an incompatibility between XNS Issue 5 and
    XNS Issue 4. A permanent interpretation is requested permitting implementations
    to use the prototype specified in XNS Issue 5.

    Portable XPG4 applications will only access the error string that is returned
    by t_strerror() for reading, and will not be affected by this slight
    relaxation of the test assertion. Most applications will not see any new
    compilation warnings due to this change. Usually such applications just pass
    the return value of this function call directly to printing or logging
    functions which are variable argument functions. However this change can
    introduce compiler warnings for a few applications that assign its return
    value to a "char *" not qualified with a const.

    The rationale for this request is XNET resolution XNET49-1
    (used in PINT4.009) and the notes from the Base WG teleconference
    of August 12th 1997, where it states:
    "With respect to items related to changes between the two
    relevant POSIX.1 versions, and other changes between XSH4v2 and XSH5,
    the group agrees in principle but recommends that these also be
    reviewed on a case-by-case process (as above)."

    Test Output
    /tset/XTI.hdr/misc/xti/T.xti 66 Further Information Provided

    Test Description:
    The <xti.h> header file contains a declaration or prototype for
    t_strerror().
    A prototype is required in UNIX98 mode.

    Test Information:
    execution of test succeeded, but unexpected output was generated
    C compiler return status: 0
    Compiler or run-time messages or results:
    "cc66es.c", line 35: warning: assignment type mismatch:
    pointer to char "=" pointer to const char
    "cc66es.c", line 38: warning: assignment type mismatch:
    pointer to function() returning pointer to char "=" pointer to
    function(int) returning pointer to const char

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The compiler warning message could be avoided by enclosing the different
    versions of the t_strerror() function in appropriate #ifdef compiler
    directives.

    While this only causes a warning from the compiler used during the
    building of the test suite, the use of a different compiler may cause
    the type difference to be reported as an error.

    This is not a serious problem and it may be appropriate to grant a waiver,
    though it should probably be granted as a minor system deficiency rather
    than as a grey area in the specification. The submitter's comments suggest
    that the test suite and the specification are both clear that t_strerror() is
    to return a char * for XNET4 systems.

    It is suggested that this is forwarded to the interpretations group.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The wording of the specification is clear. Moreover, the compiler warning
    message could be avoided by enclosing the different versions of the
    t_strerror() function in appropriate #ifdef compiler directives. A
    Permanent Interpretation or Permanent Waiver should not be granted.

    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:

     

    Back   

Contact the Certification Authority