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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0531 Actions

    Problem Report Number 0531
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0150
    Raised 2002-04-25 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.4.5
    Test Identification POSIX.os/ioprim/fcntl 6 7 8
    Problem Summary PG4R.151 This submittal is to put refused interp X/Open Reference: req.4.2.614 out for 14 day review to the base working group. The original reason for this request is as follows: An implementation specific fl...
    Problem Text
    This submittal is to put refused interp X/Open Reference: req.4.2.614
    out for 14 day review to the base working group.

    The original reason for this request is as follows:

    An implementation specific flag,
    O_LARGEFILE, is set on by default when the file is created by open().
    This flag is still on after the fcntl() calls in these testcases, and
    the testcases aren't expecting this flag to be on.

    There is nothing in the spec that prevents an implementation from
    having additional implementation specific flags such as this.

    The testsuite should allow for this.

    Which was refused for the following reason:

    It is true that the specification does not prevent implementations from
    having additional file status flags. However, the description of open()
    says, `The file status flags and file access modes of the open file
    description will be set according to the value of oflag.'

    This seems to imply that only the file status flags passed in oflag
    can be set, in which case an implementation which returns additional
    flags from fcntl(F_GETFL) that were not set in the oflag argument to
    open() (or in an fcntl(F_SETFL) call) does not comply with the
    specification.

    While the wording `according to the value' is perhaps not as clear as
    it could be, it is difficult to see how any interpretation of those
    words which allowed additional implementation-specific flags to be set
    would not also allow additional standard flags (such as O_NONBLOCK)
    to be set. Clearly the latter would be very undesirable.

    Therefore I believe that the intention must be for the file status
    flags to be set to those passed in oflag, and only those, and this
    implementation does not comply with that requirement.

    It is recommended that this request is refused.

    Additional Commentary regarding asking for the 14 day reveiw:

    The consultant's rationale in refusing this interp applying for a test
    suite deficiency was not based on anything in fcntl(), but rather was based
    on the following phrase in the description of open().

    "The file status flags and file access modes of the open file description
    will be set according to the value of oflag"

    He acknowledged the spec's choice of words "set according to" was not very
    clear but he was concerned "it is difficult to see how any interpretation
    of those words which allowed additional implementation-specific flags to be
    set would not also allow additional standard flags (such as O_NONBLOCK)to
    be set."

    We don't agree with that concern, and don't understand why an
    interpretation could not be phrased that would make it clear that
    additional standard flags (such as O_NONBLOCK) cannot be set by default.

    POSIX 1003.1-1996 states "one must read the current flag values, then
    modify accordingly, since just doing a
    F_SETFL will make it so that only the bit(s) you asked for is set" . These
    VSX fcntl() testcases definately do not first read the existing flags,
    modify them, and then reset them, as they should according to POSIX
    1003.1-1996. That omission is not an implementation issue, it's a
    testsuite issue.

    test6 for example, tests that a call to fcntl(fildes, F_SETFL, O_NONBLOCK)
    shall set the file status flag O_NONBLOCK for filedes. test6 calls open(),
    with O_RDWR|O_CREAT and then call fcntl() with F_SETFL with only the arg
    O_NONBLOCK. It is then expecting only the O_RDWR and O_NONBLOCK flags to
    be set. On our implementation the O_RDWR & O_NONBLOCK flags are on.
    Our implementation's fcntl() call successfully set the O_NONBLOCK status
    flag as it always has, and it has always passed these testcases until
    now.The issue is that for this particular release and beyond, O_LARGEFILE,
    an implementation specific flag, is also on, and the test doesn't like
    that.

    The implementation specific flag O_LARGEFILE is set on by default by the
    open() call in this and later releases given the default compiler options,
    which are the compiler options used in branding runs. It was not set by
    fcntl(). It is on immediately after the open() -- the testsuite never
    issued a F_GETFL to check - and is still on after the successful fcntl()
    F_SETFL call.

    Test Output

    ************************************************************************
    /tset/POSIX.os/ioprim/fcntl/T.fcntl 6 Failed

    Test Description:
    A call to fcntl(fildes, F_SETFL, O_NONBLOCK) shall set the file status
    flag O_NONBLOCK for fildes.
    Posix Ref: Component FCNTL Assertion 6.5.2.2-10(A)

    Test Strategy:
    OPEN file with (O_CREAT | O_RDWR)
    SET file status flags to O_NONBLOCK using fcntl(F_SETFL)
    VERIFY fcntl(F_GETFL) returns (O_RDWR | O_NONBLOCK)
    CLOSE file and OPEN it again (O_RDWR | O_NONBLOCK | O_APPEND)
    SET file status flags to O_NONBLOCK using fcntl(F_SETFL)
    VERIFY fcntl(F_GETFL) returns (O_RDWR | O_NONBLOCK)

    Test Information:
    fcntl(F_SETFL) did not set flags properly, fcntl(F_GETFL) returned
    02007, expected 07
    fcntl(F_SETFL) did not set flags properly, fcntl(F_GETFL) returned
    02007, expected 07

    ************************************************************************
    ************************************************************************
    /tset/POSIX.os/ioprim/fcntl/T.fcntl 7 Failed

    Test Description:
    A call to fcntl(fildes, F_SETFL, O_APPEND) shall set the file status
    flag O_APPEND for fildes.
    Posix Ref: Component FCNTL Assertion 6.5.2.2-11(A)

    Test Strategy:
    OPEN file with (O_CREAT | O_RDWR)
    SET file status flags to O_APPEND using fcntl(F_SETFL)
    VERIFY fcntl(F_GETFL) returns (O_RDWR | O_APPEND)
    CLOSE file and OPEN it again (O_RDWR | O_NONBLOCK | O_APPEND)
    SET file status flags to O_APPEND using fcntl(F_SETFL)
    VERIFY fcntl(F_GETFL) returns (O_RDWR | O_APPEND)

    Test Information:
    fcntl(F_SETFL) did not set flags properly, fcntl(F_GETFL) returned
    02013, expected 013
    fcntl(F_SETFL) did not set flags properly, fcntl(F_GETFL) returned
    02013, expected 013

    ************************************************************************
    ************************************************************************
    /tset/POSIX.os/ioprim/fcntl/T.fcntl 8 Failed

    Test Description:
    A call to fcntl(fildes, F_SETFL, O_APPEND|O_NONBLOCK) shall set the
    file status flags O_NONBLOCK and O_APPEND for fildes.
    A call to fcntl(fildes, F_SETFL, 0) shall clear the file status flags
    for fildes.
    Posix Ref: Component FCNTL Assertion 6.5.2.2-12(A)

    Test Strategy:
    OPEN file with (O_CREAT | O_RDWR)
    SET file status flags to (O_NONBLOCK | O_APPEND) using fcntl(F_SETFL)
    VERIFY fcntl(F_GETFL) returns (O_RDWR | O_NONBLOCK | O_APPEND)
    CLOSE file and OPEN it again (O_RDWR | O_NONBLOCK | O_APPEND)
    SET file status flags to 0 using fcntl(F_SETFL)
    VERIFY fcntl(F_GETFL) returns O_RDWR

    Test Information:

    fcntl(F_SETFL) did not set flags properly, fcntl(F_GETFL) returned
    02017, expected 017
    fcntl(F_SETFL) did not set flags properly, fcntl(F_GETFL) returned
    02003, expected 03

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The advice that POSIX gives to application writers that they should
    read the current flag values and modify them is necessary because
    applications can inherit file descriptors whose flag settings are
    not under their control. For files opened by the application itself,
    only the flags passed to open() are set, and so it is safe to set
    the new flags `from scratch'. The application already knows which
    flags are set for the descriptor - it doesn't need to use
    fcntl(F_GETFL) to obtain them first. (It would still be good
    programming practice to do so, but it's not strictly necessary.)

    These fcntl() tests rely on the fact that open() does not set any
    file status flags in addition those requested by the application,
    and that is why the previous refusal of this request was based on
    the behaviour of open() on this implementation.

    When I said "it is difficult to see how any interpretation of those
    words ...", I was using the word "interpretation" with its normal
    English meaning, not in the sense of the outcome of an
    "interpretation request". I.e. I was referring to what possible
    meaning(s) the current words can have. It would, of course, be
    possible for the final decision resulting from this interpretation
    request to be that open() can set additional non-standard status
    flags but cannot set additional standard status flags. However,
    such a decision would have to acknowledge that the current wording
    is incorrect, because the only possible meanings of those words
    are either that no additional flags can be set or that any
    additional flags (both standard and non-standard) can be set.
    Of those two possible meanings, obviously the former is greatly
    more desirable than the latter.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request is being sent for a 14 day formal review by the Base Working
    Group

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The Base WG concurred that the waiver request should be denied. The spec
    clearly says that fcntl(fd, SETFL, flags) sets the file status flags to
    the bits designated as file status flags in the flags argument.

    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