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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0352 Actions

    Problem Report Number 0352
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Temporary Interpretation (TIN)
    Problem Resolution ID TIN.X.0004
    Raised 1992-09-07 08:00
    Updated 2003-03-13 08:00
    Published 1992-10-06 08:00
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.2.3
    Test Identification ANSI.os/streamio/fseek 12
    Specification System Interfaces and Headers Issue 4
    Location in Spec See Problem Text
    Problem Summary TIN4.004 The test checks for ESPIPE and then goes on to test for an additional requirement that the file offset will not be affected by the fseek(). There is no requirement for this, in fact XPG4 page 156 fsee...
    Problem Text

    The test checks for ESPIPE and then goes on to test for an additional
    requirement that the file offset will not be affected by the fseek().
    There is no requirement for this, in fact

    XPG4 page 156 fseek() states:

    ``The behaviour of fseek() on devices which are incapable of seeking
    is implementation defined. The value of the file offset asscociated
    with such a device is undefined.''

    Thus, this part of the test should be removed. This flaw is in both
    VSX4.2.3 and VSX4.2.4.
    Test Output
    ************************************************************************
    /tset/ANSI.os/streamio/fseek/T.fseek 12 Failed

    Test Description:
    ESPIPE in errno and a non-zero return value when fseek() is called and
    the stream pointer is associated with a pipe or FIFO.
    Posix Ref: Component FSEEK Assertion 8.2.3.11-10(A)

    Test Strategy:
    CREATE FIFO using mkfifo()
    SET timeout using SET_TIMEOUT
    OPEN FIFO readonly and nonblocking using open()
    CLEAR alarm using CLEAR_ALARM
    SET timeout using SET_TIMEOUT
    OPEN FIFO writeonly and nonblocking using open()
    CLEAR alarm using CLEAR_ALARM
    OPEN stream on read side of FIFO using fdopen()
    WRITE string to FIFO
    READ byte from stream using getc()
    VERIFY first byte of string was read
    CALL fseek() on stream
    VERIFY that a non-zero value was returned and errno was set to ESPIPE
    READ byte from stream using getc()
    VERIFY second byte of string was read
    OPEN pipe from subprogram which writes a string to stdout, using
    popen()
    READ byte from stream using getc()
    VERIFY first byte of string was read
    CALL fseek() on stream
    VERIFY that a non-zero value was returned and errno was set to ESPIPE
    READ byte from stream using getc()
    VERIFY second byte of string was read

    Test Information:
    getc() after fseek() on FIFO did not return next byte written to FIFO
    getc() after fseek() on pipe did not return next byte written to pipe
    ************************************************************************

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    My understanding of the manner in which this is dealt with in the
    POSIX.1 and XPG 4 specifications is that the behaviour of the fseek()
    function is, in some way, related to the underlying lseek(). First it would
    be sensible to establish the behaviour of lseek(). My understanding is that
    the implementation in question does not lose any data when an lseek() is
    undertaken on a pipe or FIFO, the corresponding tests in this area have not
    been questioned even though the wording is very similar. The comments in
    the request relating to devices and the behaviour of fseek()/lseek() on
    devices which are not capable of seeking seem to be irrelevant since pipes
    and FIFOS do not come within the definition of devices. The behaviour of
    lseek() on pipes and FIFOs is clearly defined to produce an error (ESPIPE)
    and not to change the file offset (which doesn't exist for a pipe or FIFO!).
    It would seem reasonable to interpret the phrase "and the file offset will
    remain unchanged" for a pipe and FIFO to mean that a subsequent read()
    will take place from the current position. In general it is accepted that
    in the case of error conditions there should not be side effects
    undefined in the standard, otherwise the most bizarre side effects could be
    considered conforming.

    The next question is what is to happen in the case that an fseek()
    is made on a pipe or FIFO. The implementation in question seems to be
    clearing the stdio buffer before it is established that the file type is a
    pipe or FIFO, this is acceptable behaviour for regular files where data can
    be retrieved from stable storage on a subsequent read() or write(). The
    question is whether this is acceptable behaviour on a pipe or FIFO where
    the data cannot be retrieved and data loss occurs. (I personally believe
    this to be undesirable behaviour, but that does not necessarily mean that
    it is not allowable by the standard).

    The part of the XPG quoted as a rationale for accepting the behaviour
    exhibited relates to devices rather than to pipe and FIFO file types.
    The test makes no requirement on devices, it only makes requirements
    related to the pipe and FIFO file types which are not devices and for
    which the behaviour is well defined in the standard.

    In responding to this request it is important to ascertain whether or not it
    is correct for an application to rely on the subsequent data after a call to
    fseek() on a pipe or FIFO. This needs to be viewed from two points, firstly,
    what the standard does and does not say, and, secondly, what the application
    needs to do to avoid the problem.

    Looking at XPG 4 we have,

    (1) That a call to fseek() on a pipe or FIFO indicates an ESPIPE error.

    (2) No discussion on any change in the file pointer, stream offset etc.
    The only discussion of this relates to devices not pipes and FIFOs.

    (3) No note that the behaviour is undefined or implementation dependent.
    Again the discussion on this relates to devices.

    (4) No discussion of side effects that can occur from the usage of the
    fseek() function in this manner.

    Looking at the implementation we have,

    (1) A side effect that the buffer is cleared on a call to fseek() with
    resultant loss of data.

    Looking from the applications viewpoint we have,

    (1) An inability to safely use the fseek() call when data is being read
    from a pipe or FIFO.

    (2) A resulting requirement to examine the file type before a call to
    fseek() can be made. This is possible through the use of the fstat()
    function, though this function is not available to a program written
    purely in ANSI C. For an ANSI C program, it seems that the only
    alternative is to expect no data loss and read and discard the
    appropriate number of bytes.

    In summary, I am concerned that an implementation may exhibit data
    loss under these conditions. I believe that the arguments relating to
    implementation defined and unspecified behaviour are not applicable since
    pipes and FIFOs are not categorised as devices. I believe that the behaviour
    of lseek() is separately defined for pipes and FIFOs, though the wording
    relating to error conditions does not clearly cover the condition where no
    file pointer exists. I agree that the manner in which the lseek() description
    has been applied to fseek() as an underlying function in the POSIX.3.1 assertion
    is less than satisfactory. I am concerned that data loss occurs under
    these conditions and believe that an application programmer would not be aware
    of this possibility.

    I find difficulty in recommending that a permanent waiver be granted for this
    problem and would suggest that this is forwarded for wider review and
    interpretation.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Temporary Interpretation (TIN)
    Review Conclusion
    A Temporary Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority