bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: POSIX requires checking all *printf return values?!?


From: Nick Stoughton
Subject: Re: POSIX requires checking all *printf return values?!?
Date: Fri, 19 Oct 2007 11:49:17 -0700

The C standard is starting a revision ... while you may be too late for
POSIX, you are NOT too late for C! Please consider writing a paper for
the C committee; the paper should include background on why the feature
is required, where it has been implemented, and proposed words for the
standard.

The entire question of when the error indicator for a file stream is set
comes from C anyway, so if there's a problem, it should be fixed in C
before it is fixed in POSIX. 

In the C standard, the FILE object is described as:
FILE
which is an object type capable of recording all the information needed
to control a stream, including its file position indicator, a pointer to
its associated buffer (if any), an error indicator that records whether
a read/write error has occurred, and an end-of-file indicator that
records whether the end of the file has been reached;

This states that the "error indicator" is only associated with
read/write errors.

Various functions are defined as setting or clearing the indicator,
including fflush(), fgetc(), fputc(), getc(), getchar(), putc(),
putchar(), fseek(), fsetpos(), rewind(), clearerr(), and all the wide
char equivalents. In every case, where the text states the indicator is
set, it is set "if a read error" or "if a write error" occurs.

So I do not see any current requirement that the error indicator should
be set for ENOMEM or EILSEQ; applications should always check the return
value of printf to see if it is negative, and then check errno if it is.
Now, I know this is a rule we all break more often than not, but that
doesn't make it a "silly" rule.
-- 
Nick

On Fri, 2007-10-19 at 11:45 -0600, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Jim Meyering on 10/19/2007 11:30 AM:
> >> Is it worth changing
> >> POSIX to require ferror() to be reliably set?  Or is it at least worth
> > 
> > How about *allowing* ferror to be reliably set?
> 
> Which brings up another issue (although it is too late to get this into
> the next revision of POSIX) - it would be really nice to have an fseterr()
> function.  Here's part of what gnulib had to do in order to write a
> POSIX-compliant wrapper around fprintf for broken platforms:
> 
> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/fseterr.c;h=4ca0a34;hb=78da34d
> 
> It breaks into the opaque FILE* on platforms where this is possible, but
> otherwise, is stuck using a six-syscall workaround just to force a stream
> to set its ferror() flag.
> 
> - --
> Don't work too hard, make some time for fun as well!
> 
> Eric Blake             address@hidden
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
> Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHGO0u84KuGfSFAYARAvQZAKCoVaNb7JSU5/pn8ImkZVEmKPnVpgCgsf08
> opYJPPcMNwGqgoFyagrUyrI=
> =lQ9H
> -----END PGP SIGNATURE-----
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]