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

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 0382 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 0382.

Report 0382 Actions

    Problem Report Number 0382
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0001
    Raised 1992-07-17 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.2.3
    Test Identification POSIX.hdr/misc/unistd_3 48
    Problem Summary PG4R.001 It is clear from XPG4 and ISO/IEC 9899 supports this view, that it is perfectly allowable to add identifier names to the argument list definition in function prototypes. The verification suite objects...
    Problem Text
    It is clear from XPG4 and ISO/IEC 9899 supports this view, that
    it is perfectly allowable to add identifier names to the argument list
    definition in function prototypes. The verification suite objects
    vehemently to this usage diametrically opposing the above standards.

    There is a rumour that this is disallowed because the names pollute
    name space. This view is totally unsupportable since function prototypes
    effectively have their own name space. Section 6.1.2.1 of the ISO standard
    states most clearly that

    "An identifier is visible (ie can be used) only within a region of
    program text called its scope. There are four kinds of scopes:
    function, file, block and function prototype. ...

    &...If the declarator or type specifier that declares the identifier
    appears within the list of parameter declarations in a function
    prototype (not part of a function definition),
    the identifer has function prototype scope, which terminates at the
    end of the function declarator. If an outer declaration of a lexically
    identical identifier exists in the same name space, it is hidden until
    the current scope terminates, after which it again becomes visible."

    This means that the potential pollution in the ordinary identifier
    name space never occurs because steps are taken to ensure that the
    existing identifier (or subsequent identifiers) which are lexically
    identical to the function prototype identifier never coexist in the
    same scope.

    Furthermore, the ISO standard explicitly allows this usage as section
    6.5.4.3 declares:

    "A parameter type list specifies the types of, and may declare identifiers
    for, the parameters of the function.
    &...
    The identifiers ... are declared for descriptive purposes only and
    go out of scope at the end of the declaration ... ."

    No restrictions are placed on the names that can be used by either
    standard. Indeed both standards specify all library functions in
    terms of function prototypes with identifiers included. Our errors
    occurred because we copied the standards' definitions verbatim into
    our header files.

    Although this waiver has been raised against a specific test, this
    problem is occurs throughout the test area. We are not applying
    for a waiver as such, but this problem has implications that
    should be resolved using the waiver request mechanism. It
    may be possible to deal with this problem in other ways.
    Test Output
    ...
    Test 48
    Feature test macros: -D_XOPEN_SOURCE
    Compiler or run-time messages or results:
    ...
    Illegal parameter name in prototype: path
    Illegal parameter name in prototype: amode
    Illegal parameter name in prototype: seconds
    ...

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The problem that arises from the inclusion of identifier names in the
    argument list is that the macro namespace becomes polluted. A program
    is allowed to include macro definitions prior to the inclusion of
    header files and these macro definitions could result in the expansion
    of identifier names in the argument list definition in function prototypes.
    The simple example of

    #define path 50
    #include <unistd.h>

    would become unportable in the case that <unistd.h> included a prototype
    of the form:

    long pathconf(char * path, int name)

    This type of namespace pollution was not considered acceptable by some of
    the advisors on the development of the VSX4 product and these tests were
    added to resolve these problems.

    It is also natable that the rationale to the C standard provides an example
    function prototype for an extension to that standard in the following form:

    #ifdef __EXTENSIONS__
    typdef int file_no;
    extern int read(file_no _N, void * _Buffer, int _Nbytes);
    /*...*/
    #endif
    This example is careful to ensure that the identifiers used within the argument
    list are names that are reserved for any use. This principle needs to be
    followed for all VSX4 conforming systems.


    It is not recommended that a waiver be granted.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This waiver request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority