Date: Tue, 23 Jan 2007 18:27:18 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-standards@FreeBSD.ORG, giecrilj@stegny.2a.pl Subject: Re: return value of fprintf Message-ID: <200701231727.l0NHRIRN074657@lurza.secnetix.de> In-Reply-To: <002401c73efd$5db24280$1a01080a@POCZTOWIEC>
next in thread | previous in thread | raw e-mail | index | archive | help
Kristof Zelechovski wrote: > Oliver Fromme wrote: > > K?i?tof ?elechovski <giecrilj@stegny.2a.pl> wrote: By the way, I'm sorry that my MUA mangled your name. Unfortunately I only have ISO-8859-1 and 8859-15 at this particular client, not 8859-2 or ISO-10646 (unicode). > > > 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. That cannot happen if you always check the return code from I/O functions. If you don't do that, well, then you should expect undesired behaviour in such situations. If an application ignores error conditions that are reported through the exit code of library functions, well, then the application clearly has a bug. Either that, or the programmer didn't care because it wasn't important enough. For example, most little utilities simply don't care if writing to stdout fails for some reason. It just doesn't matter, and it doesn't justify polluting the code with hundreds of checks. C++ is different anyway for its support for exceptions, which is the normal mechanism to handle I/O errors. C doesn't support exceptions, so you have to check the return code from every I/O operation yourself. > nor do I understand why the C library prefers > to let sloppy code leave holes in data. Would you suggest that _all_ I/O operations continue to fail until the application explicitly clears the error indicator? That would break many programs. Many. In fact, I think that the existing behaviour makes more sense. For example, if one printf() failed because of ENOSPC, then the next printf() should still be performed, because the error condition might have cleared in the meantime. It should work, no matter if the programmer decided to check all return values and reset the error indicator or not. > > > 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 Right, but POSIX/SUSv3 does. And it says: "Some of the functionality described [for errno values] extends the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std 1003.1-2001 defers to the ISO C standard." > and it does not require the stream I/O functions to set errno. Right, but POSIX/SUSv3 does. See above. > Therefore, "always set" is guaranteed to work > only within the confines of POSIX, otherwise it remains unspecified. And FreeBSD aims to comply with POSIX, so there is no problem at all. 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. I suggested holding a "Python Object Oriented Programming Seminar", but the acronym was unpopular. -- Joseph Strout
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200701231727.l0NHRIRN074657>