From: ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig)
Subject: Re: Library 4.1 bug/feature? fopen("fifo","a") fails
Date: 7 Jan 1993 15:53:23 GMT
[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.
Anything wrong with the suggestion above?
-- Thomas Koenig, ig25@rz.uni-karlsruhe.de, ig25@dkauni2.bitnet The joy of engineering is to find a straight line on a double logarithmic diagram.