Date: Mon, 18 Sep 2000 15:37:24 -0400
Message-Id: <200009181937.PAA21670@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <200009171733.TAA19894@father.ludd.luth.se> (message from Martin
	Str|mberg on Sun, 17 Sep 2000 19:33:16 +0200 (MET DST))
Subject: Re: O_APPEND
References:  <200009171733 DOT TAA19894 AT father DOT ludd DOT luth DOT se>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


>   newmode = (oldmode & ~(O_BINARY|O_TEXT)) | (mode & (O_BINARY|O_TEXT));
> becomes:
>   newmode = (oldmode & ~(O_BINARY|O_TEXT|O_APPEND)) | (mode & (O_BINARY|O_TEXT|O_APPEND));

No.  setmode() shouldn't be used to change the O_APPEND mode.  It is
for text/binary changes only.

>   __file_handle_set(newfd, __file_handle_modes[fd] ^ (O_BINARY|O_TEXT));
>
>   setmode(newfd, __file_handle_modes[fd]);
> 
> I don't understand this so I don't know if O_APPEND should go beside
> O_BINARY and O_TEXT or not.

No.  This trick is here to make sure that the final setmode() actually
*does* something (i.e. it prevents setmode() from saying "oh, it's
already set right" and not doing enough).