home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / linux / 23147 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  2.6 KB
  1. Xref: sparky comp.os.linux:23147 comp.std.c:3337
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!ogicse!news.u.washington.edu!serval!hlu
  3. From: hlu@eecs.wsu.edu (H.J. Lu)
  4. Newsgroups: comp.os.linux,comp.std.c
  5. Subject: Re: Library 4.1 bug/feature?  fopen("fifo","a") fails
  6. Message-ID: <1993Jan7.232805.16555@serval.net.wsu.edu>
  7. Date: 7 Jan 93 23:28:05 GMT
  8. Article-I.D.: serval.1993Jan7.232805.16555
  9. References: <1igs2mINNdpp@nz12.rz.uni-karlsruhe.de> <1993Jan7.104939.10424@serval.net.wsu.edu> <1ihjljINNeu7@nz12.rz.uni-karlsruhe.de>
  10. Sender: news@serval.net.wsu.edu (USENET News System)
  11. Organization: School of EECS, Washington State University
  12. Lines: 45
  13.  
  14. In article <1ihjljINNeu7@nz12.rz.uni-karlsruhe.de>, ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
  15. |> [note crossposting to comp.std.c]
  16. |> 
  17. |> In article <1993Jan7.104939.10424@serval.net.wsu.edu> hlu@luke.eecs.wsu.edu (H.J. Lu) writes:
  18. |> >In article <1igs2mINNdpp@nz12.rz.uni-karlsruhe.de> ig25@rz.uni-karlsruhe.de writes:
  19. |> 
  20. |> [concerning the libc library 4.1 for Linux]
  21. |> 
  22. |> >>Is it a bug or a feature that fopen("fifo","a"), where "fifo" is a named
  23. |> >>pipe, fails with an 'illegal lseek' in the 4.1 version of the library?
  24. |> >>The opinion on comp.std.unix seems to be that there should be no
  25. |> >>problem...
  26. |> >
  27. |> >That is a feature of stdio/kernel. I was told that according to ANSI
  28. |> >standard, fopen ("foo", "a") should do a lseek () to the end after
  29. |> >calling open (). But linux kernel refuses to any lseek () on
  30. |> >non-regular files. The fixes are
  31. |> >
  32. |> >1. Change stdio such that ignore error from lseek (). I don't
  33. |> >   like this one.
  34. |> >2. Change kernel such that if a file can not lseek (), just return
  35. |> >   without error.
  36. |> >3. Change kernel such that if a file can not lseek (), just return
  37. |> >   with a special error which can be recognized by stdio that a
  38. |> >   lseek is requested on a non-suported file.
  39. |> >4. Change your source code to use fopen ("foo", "w").
  40. |> 
  41. |> [rest deleted]
  42. |> 
  43. |> From my understanding of the ANSI C standard, the main thing is not to
  44. |> overwrite anything in a file opened with mode "a".  It should be legal
  45. |> to implement the stdio library in such a way that, when opening a fifo
  46. |> in "a" mode, no lseek() call is made.  A later fseek() - call to a
  47. |> stream opened for append should be ignored, anyway.
  48.  
  49. No. Fseek () should not be ignored if fopen ("foo", "a+") is used.
  50.  
  51. |> 
  52. |> Anything wrong with the suggestion above?
  53.  
  54. Have you tried my test code? Some Unices just ignore lseek (). FIFO is just
  55. one type of file, on which lseek cannot be done. We have char devices and
  56. sockets. I prefer stdio should not know so much details about the kernel.
  57.  
  58. H.J.
  59.