home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0053.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  2.3 KB
  1. From:  Doug Gwyn <gwyn@smoke.brl.mil>
  2.  
  3. In article <735@longway.TIC.COM> From: Paul Rabin <rabin@osf.org>
  4. >Section 6.5.3.4 specifies that lseek() returns EINVAL if the resulting 
  5. >file offset would be invalid, but it doesn't say which file offsets
  6. >are invalid.
  7.  
  8. That's right; it would be overspecification to try to spell out which
  9. file offsets are required to be valid.
  10.  
  11. >    An illegal file offset that would cause [EINVAL] to be
  12. >    returned may be both implementation defined and device
  13. >    dependent (for example, memory may have few illegal values).
  14. >    A negative file offset may be legal for some devices in
  15. >    some implementations.
  16.  
  17. The rationale is also right.
  18.  
  19. >The standard does not specify an error for I/O operations attempted at
  20. >an illegal offset. It _seems_ that the intent is for an offset to be legal
  21. >only if some I/O operation is possible at that offset, and for it to be
  22. >impossible to set an illegal offset.  This is not changed in the 1990
  23. >revision of the standard or in the P1003.1b supplement.
  24.  
  25. I/O even at a valid offset may nonetheless fail, depending on the type
  26. of file and on various circumstances.  It is certainly the intent of a
  27. successful lseek() that under appropriate circumstances a subsequent
  28. I/O operation MIGHT succeed, but it is not required.  (Consider lseek()
  29. to the end of a non-extendable file.)
  30.  
  31. >Some implementations do permit lseek() to set "illegal" file offsets,
  32. >and some applications take advantage of this.  Does anyone know whether
  33. >the original members of the 1003.1 working group intended to permit this?
  34.  
  35. If lseek() reports failure, the attempted offset should not stick.
  36. Otherwise, it should.  The absolute offset may be negative and succeed
  37. for some file types; this was intentional.  For example, on a process
  38. opened as a file a negative offset may be useful to access registers and
  39. the u-area.
  40.  
  41. >Does anyone have an implementation that returns [EINVAL] if the
  42. >file offset resulting from lseek() is negative, or positive and "too
  43. >large"?  Are file offsets represented in your kernel by a signed or an
  44. >unsigned type?
  45.  
  46. On 4.3BSD, lseek() to a negative absolute offset on an ordinary file
  47. reports success and returns the (negative) absolute offset.  This is
  48. probably a bug rather than a feature, since I'm sure no valid data can
  49. be returned from the negative bytes of an ordinary file.
  50.  
  51. Volume-Number: Volume 20, Number 52
  52.  
  53.