*BSD News Article 2624


Return to BSD News archive

Path: sserve!manuel!munnari.oz.au!uunet!darwin.sura.net!mips!sdd.hp.com!uakari.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!serval!phys1.physics.wsu.edu!hlu
From: hlu@phys1.physics.wsu.edu (Hongjiu Lu)
Newsgroups: comp.unix.bsd
Subject: Re: STDIO Mode "a+" screwed up
Message-ID: <1992Jul27.235032.2655@serval.net.wsu.edu>
Date: 27 Jul 92 23:50:32 GMT
References: <39897@gremlin.nrtc.northrop.com>
Sender: news@serval.net.wsu.edu (USENET News System)
Organization: Washington State University
Lines: 32

In article <39897@gremlin.nrtc.northrop.com>, dec@lazarus.nrtc.northrop.com (Dwight E. Cass) writes:
|> Hi folks,
|> 
|>    I have just spent the weekend trying to find out why rogue crashes
|> when it attempts to update its score file and have found the problem:
|> 
|>    In: /usr/src/lib/libc/stdio/flags.c - Mode "a+" translates to an
|>        open flag with O_APPEND (in __sflags()).  This means that if
|>        you seek the file to the beginning and start writting, all the
|>        written will be APPENDED to the end of the file - rather than
|>        updating the top of the file as specified by the plus sign.
|> 
|>    What's the cure - ouch.  It seems that __sflags() is called by all of
|> the open routines and that there is not a clean way of passing back
|> the fact that append is desired (why pass it back - you have to seek
|> to the bottom of the file [lseek (fd, 0, SEEK_END)] after the file
|> is opened (i.e., after you have returned from __sflags()).  So - my
|> proposal (which I will implement tonight and send patches for
|> tommorrow), add one more flag to the ->flags work in the FILE *
|> structure.  This flag, __SUPD 0x4000, will indicate that the file
|> has been opened in an append mode (i.e., I will always set this flag
|> for "a", "a+", "ab+", and look at it rather than O_APPEND to make the
|> decision as to whether to lseek or not.)  We will see what
|> side-effects this has.
|> 

I think that is the right behavior according to ANSI C. Unfortunately some
UNICES screw up on this one.

-- 
H.J.
Gcc/libc maintainer for Linux.