From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123148 invoked by alias); 3 Feb 2017 15:11:19 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 123131 invoked by uid 89); 3 Feb 2017 15:11:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Mode, heinzmann, H*f:sk:23012be, Heinzmann X-HELO: mail02.lgsinnovations.com Received: from mail02.lgsinnovations.com (HELO mail02.lgsinnovations.com) (63.149.110.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 Feb 2017 15:11:17 +0000 Subject: Re: fopen() behavior: File positioning in append mode To: References: <23012be5-2810-3215-da19-374c7c081b68@gmx.de> From: Craig Howland Message-ID: <597e6b01-26fb-f80d-6c48-209e7052b297@LGSInnovations.com> Date: Fri, 03 Feb 2017 15:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <23012be5-2810-3215-da19-374c7c081b68@gmx.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LGS-EX02.lgsdirect.com (135.22.77.165) To LGS-EX01.lgsdirect.com (135.22.77.164) X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00125.txt.bz2 On 02/03/2017 05:59 AM, Stefan Heinzmann wrote: > Hi, > > I am unsure what the behavior of fopen() should be when the "a+" mode is > given. The source for this is in file newlib/libc/stdio/fopen.c > > Mode a+ translates to open() flags O_RDWR|O_CREAT|O_APPEND according to the > POSIX standard. This would set the file position to the beginning of the file. > The file position would be relevant only to read operations, since the > O_APPEND flag causes writes to happen at the file end in any case. > > However, fopen() seems to set the file position to the end in this case, by > calling fseek() explicitly. The consequence is that read operations also > happen at the file end. I don't understand why this is done. Wouldn't it be > more useful to omit the call to fseek(), or to restrict it to the write-only > case? > > The C standard doesn't seem to be clear here. Does it actually specify what > the result of ftell() should be immediately after calling fopen()? I seem to > be unable to find conclusive text. > > Thanks > Stefan See C99 section 7.19.3, where it defines that, if a file does support positioning requests, the initial position is 0 unless the file is opened in append mode. If the file is opened in append mode, then the initial position is implementation defined. So there is conclusive text, but it does allow a choice. I suggest that the newlib implementation choice makes sense. The "a" mode opens for writing only at the end of the file. Using a+ adds the ability to read, also. Since it is based on "a", starting at the end makes sense. The user could also choose r+--based on r--in which case a reasonable assumption (and the required behavior) is that it would start at 0 for read. This line of reasoning (which I thought of before checking the code) is borne out by the actual implementation--the fseek happens if "a" was used. Craig