Use of the information contained in this unapproved document is at your own risk.

Last update: 10 April,2001

                                                                1003.1-90 #39
	Classification:  The unaddressed issue.

This is being referred to the sponsor for clarifying wording in the
next amendment.  This will be forwarded to the IEEE for incorporation 
into an IEEE interpretations publication, and will be also made available 
on-line on the IEEE SPAsystem.

This interpretation does not necessitate any modification to 
assertions in IEEE Std 2003.1-1992.
 _____________________________________________________________________________


	Interpretation Number:	(to be added by the IEEE)
	Topic:			F_SETLKW and seek()
	Relevant Sections:	not specified


Interpretation Request: (Defect Report)
-----------------------

    Advisory locking is imprecise on what byte of a file is locked when
    using F_SETLKW and either SEEK_CUR or SEEK_END.  Once blocked, the
    address could be that on entry, or established after the process is no
    longer blocked.  From e-mail, discussions, it appears the address is
    calculated before the decision to block, and does not change.

IEEE Interpretation for 1003.1-1990 (9945-1:1990):
--------------------------------------------------

    The standard does not speak to this issue, and as such no conformance
    distinction can be made between alternative implementations based on
    this.  This is being referred to the sponsor for clarifying wording in
    the next amendment. 


Rationale for Interpretation:
-----------------------------
    The standard doesn't specify the behavior in this case.  It is clear,
    however, that the request must use one of the file size or seek
    pointers that was in effect while the fcntl() was being serviced.  The
    email discussions about how existing implementations work is not
    relevant.

 _____________________________________________________________________________