home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / linux / 23160 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  3.0 KB
  1. Xref: sparky comp.os.linux:23160 comp.std.c:3339
  2. Newsgroups: comp.os.linux,comp.std.c
  3. Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!jit345.bad.jit.dec.com!diamond
  4. From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
  5. Subject: Re: [Linux] Library 4.1 bug/feature?  fopen("fifo","a") fails
  6. Message-ID: <1993Jan8.012236.28983@nntpd.lkg.dec.com>
  7. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  8. Reply-To: diamond@jit.dec.com (Norman Diamond)
  9. Organization: Digital Equipment Corporation Japan , Tokyo
  10. References: <1igs2mINNdpp@nz12.rz.uni-karlsruhe.de> <1993Jan7.104939.10424@serval.net.wsu.edu> <1ihjljINNeu7@nz12.rz.uni-karlsruhe.de>
  11. Date: Fri, 8 Jan 1993 01:22:36 GMT
  12. Lines: 40
  13.  
  14. In article <1ihjljINNeu7@nz12.rz.uni-karlsruhe.de> ig25@rz.uni-karlsruhe.de writes:
  15. >In article <1993Jan7.104939.10424@serval.net.wsu.edu> hlu@luke.eecs.wsu.edu (H.J. Lu) writes:
  16. >>In article <1igs2mINNdpp@nz12.rz.uni-karlsruhe.de> ig25@rz.uni-karlsruhe.de writes:
  17. >>>Is it a bug or a feature that fopen("fifo","a"), where "fifo" is a named
  18. >>>pipe, fails with an 'illegal lseek' in the 4.1 version of the library?
  19. >>>The opinion on comp.std.unix seems to be that there should be no problem...
  20.  
  21. >>That is a feature of stdio/kernel. I was told that according to ANSI
  22. >>standard, fopen ("foo", "a") should do a lseek () to the end after calling
  23. >>open (). But linux kernel refuses to any lseek () on non-regular files.
  24.  
  25. >From my understanding of the ANSI C standard, the main thing is not to
  26. >overwrite anything in a file opened with mode "a".
  27.  
  28. That is my understanding too.  However, note that the ANSI C standard is
  29. concerned only with files on this matter.  The ANSI C standard also states
  30. that certain kinds of data, written to certain kinds of files, can be read
  31. back unchanged.  I think that named pipes cannot be considered as ANSI C
  32. files, only as implementation extensions.  The standard does not really
  33. constrain extensions.  Conforming implementations must still guarantee that
  34. strictly conforming programs will not observe a difference, but strictly
  35. conforming programs cannot use named pipes, so anything goes for named pipes.
  36.  
  37. >It should be legal to implement the stdio library in such a way that, when
  38. >opening a fifo in "a" mode, no lseek() call is made.
  39.  
  40. I believe that such an extension would remain friendly as well as not
  41. violating the standard (though the standard doesn't care about friendliness).
  42.  
  43. >A later fseek() call to a stream opened for append should be ignored, anyway.
  44.  
  45. For named pipes, maybe this would be OK, purely for the above reason, that
  46. named pipes are entirely implementation extensions.  However, for ANSI C
  47. files, this would not be OK.  There are cases with ANSI C files where, even
  48. if a stream is opened for append, and even though writes will be forced to
  49. the end of the file, fseek() cannot be ignored.
  50. --
  51. Norman Diamond                diamond@jit.dec.com
  52. If this were the company's opinion, I wouldn't be allowed to post it.
  53. Pardon me?  Or do I have to commit a crime first?
  54.