return value of fprintf

Oliver Fromme olli at
Tue Jan 23 17:27:26 UTC 2007

Kristof Zelechovski wrote:
 > Oliver Fromme wrote:
 > > K?i?tof ?elechovski <giecrilj at> 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

 > 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 Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD:
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

More information about the freebsd-standards mailing list