From: hlu@eecs.wsu.edu (H.J. Lu)
Subject: Re: Library 4.1 bug/feature? fopen("fifo","a") fails
Date: 7 Jan 1993 23:28:05 GMT
In article <1ihjljINNeu7@nz12.rz.uni-karlsruhe.de>, ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
|> [note crossposting to comp.std.c]
|>
|> In article <1993Jan7.104939.10424@serval.net.wsu.edu> hlu@luke.eecs.wsu.edu (H.J. Lu) writes:
|> >In article <1igs2mINNdpp@nz12.rz.uni-karlsruhe.de> ig25@rz.uni-karlsruhe.de writes:
|>
|> [concerning the libc library 4.1 for Linux]
|>
|> >>Is it a bug or a feature that fopen("fifo","a"), where "fifo" is a named
|> >>pipe, fails with an 'illegal lseek' in the 4.1 version of the library?
|> >>The opinion on comp.std.unix seems to be that there should be no
|> >>problem...
|> >
|> >That is a feature of stdio/kernel. I was told that according to ANSI
|> >standard, fopen ("foo", "a") should do a lseek () to the end after
|> >calling open (). But linux kernel refuses to any lseek () on
|> >non-regular files. The fixes are
|> >
|> >1. Change stdio such that ignore error from lseek (). I don't
|> > like this one.
|> >2. Change kernel such that if a file can not lseek (), just return
|> > without error.
|> >3. Change kernel such that if a file can not lseek (), just return
|> > with a special error which can be recognized by stdio that a
|> > lseek is requested on a non-suported file.
|> >4. Change your source code to use fopen ("foo", "w").
|>
|> [rest deleted]
|>
|> From my understanding of the ANSI C standard, the main thing is not to
|> overwrite anything in a file opened with mode "a". It should be legal
|> to implement the stdio library in such a way that, when opening a fifo
|> in "a" mode, no lseek() call is made. A later fseek() - call to a
|> stream opened for append should be ignored, anyway.
No. Fseek () should not be ignored if fopen ("foo", "a+") is used.
|>
|> Anything wrong with the suggestion above?
Have you tried my test code? Some Unices just ignore lseek (). FIFO is just
one type of file, on which lseek cannot be done. We have char devices and
sockets. I prefer stdio should not know so much details about the kernel.
H.J.