This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Never cache offset when the stream handle is not active (BZ #16680)


OK, I guess I could just do the seek but not cache it in fopen and
fdopen.  That way I can get rid of the stat bits and just rely on
seek_cur. For append mode I can cache the offset after seeking to end
if we have an unflushed write, like you do in musl.

Siddhesh

On 11/03/2014, Rich Felker <dalias@aerifal.cx> wrote:
> On Tue, Mar 11, 2014 at 08:24:26AM +0530, Siddhesh Poyarekar wrote:
>> On Tuesday, 11 March 2014, Rich Felker <dalias@aerifal.cx> wrote:
>>
>> > On Tue, Mar 11, 2014 at 06:09:35AM +0530, Siddhesh Poyarekar wrote:
>> > > On Mon, Mar 10, 2014 at 02:34:59PM -0400, Rich Felker wrote:
>> > > > Caching the offset is valid when writing in append mode. The one
>> > > > case
>> > > > that's special for append mode is that, even once the handle is
>> > > > active, you can't save the resulting offset at the time of
>> > > > seek/rewind
>> > > > and use it for ftell during subsequent writing. This is because the
>> > > > (first) write after seeking could change the current offset. One
>> > > > easy
>> > > > way to deal with this is to treat seek/rewind as deactivating the
>> > > > handle when the stream is in append mode, but more fine-grained
>> > > > solutions are possible too.
>> > >
>> > > Treating seek/rewind as deactivating the handle won't help for append
>> > > mode because we want to simulate the file position as being the end
>> > > of
>> > > file regardless of the file position when the handle is inactive, but
>> >
>> > Why do you want to do this? It's wrong. If the handle is inactive, the
>>
>> only way you can get the position is by calling lseek(fd,0,SEEK_CUR).
>>
>> This is because operations on another handle could have changed the
>> > position without stdio's knowledge.
>> >
>>
>> Because that would give an inconsistent result. Initial position for
>> append
>> mode files is implementation defined and glibc has set it as end of file
>> in
>> the past. Changing that would be a breakage, wouldn't it?
>
> Then fopen needs to physically seek to the end of the file with lseek
> when append mode is requested. Faking the position is non-conforming
> because it does not respect the rules for active handles.
>
> Rich
>


-- 
http://siddhesh.in


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]