From owner-freebsd-standards@FreeBSD.ORG Tue Jan 23 13:40:08 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 E977416A401 for ; Tue, 23 Jan 2007 13:40:08 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4BDF313C4C9 for ; Tue, 23 Jan 2007 13:40:07 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (bufwdi@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l0NDdv91046533; Tue, 23 Jan 2007 14:40:02 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l0NDdvF3046532; Tue, 23 Jan 2007 14:39:57 +0100 (CET) (envelope-from olli) Date: Tue, 23 Jan 2007 14:39:57 +0100 (CET) Message-Id: <200701231339.l0NDdvF3046532@lurza.secnetix.de> From: Oliver Fromme To: freebsd-standards@FreeBSD.ORG, giecrilj@stegny.2a.pl In-Reply-To: <000401c73ed9$540afca0$1a01080a@POCZTOWIEC> X-Newsgroups: list.freebsd-standards User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 23 Jan 2007 14:40:02 +0100 (CET) Cc: Subject: Re: return value of fprintf X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-standards@FreeBSD.ORG, giecrilj@stegny.2a.pl List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 13:40:09 -0000 K?i?tof ?elechovski wrote: > I have run the code in a loop and the return value is periodically -1. That's to be expected. Once in a while, the fprintf() will fill the stdio buffer, causing it to be flushed. If an error occurs during the flushing, it will be noticed and returned. That's the "if an error was encountered" case from the standard's wording. ;-) Basically, you can think of fprintf() calling fputc() repeatedly, which simply adds characters to the stdio buffer until it is full. If it's full, it gets flushed, and only then an actual I/O operation occurs, and only then an actual I/O error can occur. > 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. > 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. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. (On the statement print "42 monkeys" + "1 snake":) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when the answer is clearly "41 monkeys and 1 fat snake". -- Jim Fulton