From owner-freebsd-standards@FreeBSD.ORG Tue Jan 23 14:47:30 2007 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE3C516A403 for ; Tue, 23 Jan 2007 14:47:30 +0000 (UTC) (envelope-from giecrilj@stegny.2a.pl) Received: from shark.2a.pl (shark.2a.pl [195.117.102.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9A57313C46A for ; Tue, 23 Jan 2007 14:47:28 +0000 (UTC) (envelope-from giecrilj@stegny.2a.pl) Received: from localhost (av.2a.pl [10.0.0.99]) by shark.2a.pl (Postfix) with ESMTP id 2D303B2572; Tue, 23 Jan 2007 15:47:24 +0100 (CET) Received: from shark.2a.pl ([10.0.0.3]) by localhost (av.2a.pl [10.0.0.99]) (amavisd-new, port 10024) with ESMTP id 95277-04; Tue, 23 Jan 2007 15:46:00 +0100 (CET) Received: from POCZTOWIEC (2a-gts [217.153.29.142]) by shark.2a.pl (Postfix) with ESMTP id 520E7B25B6; Tue, 23 Jan 2007 15:47:09 +0100 (CET) From: =?us-ascii?Q?Kristof_Zelechovski?= To: , References: <000401c73ed9$540afca0$1a01080a@POCZTOWIEC> <200701231339.l0NDdvF3046532@lurza.secnetix.de> Date: Tue, 23 Jan 2007 15:47:11 +0100 Message-ID: <002401c73efd$5db24280$1a01080a@POCZTOWIEC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <200701231339.l0NDdvF3046532@lurza.secnetix.de> Thread-Index: Acc+9CGZt13QkJIwQWme36z88QdtDAABwZ9g X-Virus-Scanned: amavisd-new at 2a.pl Cc: Subject: RE: return value of fprintf X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 14:47:30 -0000 > -----Original Message----- > From: Oliver Fromme [mailto:olli@lurza.secnetix.de] > Sent: Tuesday, January 23, 2007 2:40 PM > To: freebsd-standards@FreeBSD.ORG; giecrilj@stegny.2a.pl > Subject: Re: return value of fprintf > > K?i?tof ?elechovski wrote: > > > Interestingly enough, > > although the stream error indicator is persistent, > > it is not taken into account to prevent data corruption as in C++ > streams. > > Can you describe that in more detail, please? Maybe > give a code example? I don't see how data corruption > could occur if your code is correct. > If you output A, B and C into cout and flushing of B fails, you get truncation: only A when you read it back. However, if you do the same with fprintf, you get elision: you can read back AC and B has been lost. This is what I call data corruption. It certainly can be prevented, and sometimes it can be detected afterwards that the file produced contains invalid data, only that I did not expect such a difference of behaviour here, nor do I understand why the C library prefers to let sloppy code leave holes in data. > > The reason may be that POSIX streams must set errno on failure > > (this is *not* required by the ANSI standard) > > but there is no errno value to indicate that the error condition is set > > (except EBADF - > > but the POSIX standard should be modified to allow this extension, > > since at present it only means "Bad file descriptor"). > > I'm sorry I don't understand what you mean. When the > error indicator is set, errno is always set to an > appropriate value (e.g. ENOSPC if you run out of space > on the file system). If you have an error condition > on s stream, but you ignore it and continue to perform > I/O on the stream without removing the cause of the > problem, you're on your own. You'll get undefined > behaviour. > The ANSI standard does not define ENOSPC and it does not require the stream I/O functions to set errno. Therefore, "always set" is guaranteed to work only within the confines of POSIX, otherwise it remains unspecified. And the behaviour in question is undefined in the sense that the standard does not define what happens when you a stream for I/O with the error indicator set; however, it is not defined as undefined, either. The Standard uses the term "undefined behaviour" for errors that cannot be easily diagnosed either by the compiler or by the runtime library, which is not the case; I would rather say it is unspecified and implementation-dependent. Thanks Chris