what if (f)printf returns EINTR ?
pvl_g...@yahoo.com
The Linux/POSIX man-page for (f)printf refers to fputc for conditions
where printf may fail. When I look to fputc, it's said that fputc may
fail with EINTR, interrupted by a signal.
I thus imagine that fprintf may suddenly fail with EINTR in the midst
of outputting its string.
First question: is my assumption right ?
Second question: if so, how can I recover from such condition ?
For other calls that can return EINTR, the recommendation is that the
user should explicitly test for this return value, and restart the
call. But for fprintf, I see additional difficulty, since it may have
already printed part of the string but not the entire string. If I
simply restart printf, part of my string would show twice in the
output.
Any solution for this ?
Thanks,
Pieter
Hubble
>where printf may fail. When I look to fputc, it's said >that fputc may
>fail with EINTR, interrupted by a signal.
>I thus imagine that fprintf may suddenly fail with EINTR in the midst
of outputting its string.
>First question: is my assumption right ?
Yes, seems to be correct
>Second question: if so, how can I recover from such >condition ?
Use s(n)printf to write into a buf, use write(2) or so to output. If
write returns EINTR, you can retry safely. This may even not be true
for fwrite.
Hubble.
Pascal Bourguignon
>>The Linux/POSIX man-page for (f)printf refers to fputc >for conditions
>>where printf may fail. When I look to fputc, it's said >that fputc may
>>fail with EINTR, interrupted by a signal.
>
>
>>I thus imagine that fprintf may suddenly fail with EINTR in the midst
> of outputting its string.
>
>
>>First question: is my assumption right ?
>
> Yes, seems to be correct
I don't think so.
The problem is that it's not specified wether (f)printf should issue
only one I/O syscall or if it may issue several.
printf("hello %s howdy?",name);
could be implemented as:
write(1,"hello %s howdy?",6);
write(1,name,strlen(name));
write(1,"hello %s howdy?"+8,7);
Then any EINTR could correspond to any of these write, and the client
program couldn't know from which part of the format it should restart.
Said otherwise, (f)printf must handle its own EINTR restarting.
>>Second question: if so, how can I recover from such >condition ?
>
> Use s(n)printf to write into a buf, use write(2) or so to output. If
> write returns EINTR, you can retry safely. This may even not be true
> for fwrite.
Mu.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
Geoff Clare
> "Hubble" <rei...@huober.de> writes:
>
>>>The Linux/POSIX man-page for (f)printf refers to fputc >for conditions
>>>where printf may fail. When I look to fputc, it's said >that fputc may
>>>fail with EINTR, interrupted by a signal.
>>
>>
>>>I thus imagine that fprintf may suddenly fail with EINTR in the midst
>> of outputting its string.
>>
>>
>>>First question: is my assumption right ?
>>
>> Yes, seems to be correct
>
> I don't think so.
No, the OP has it right.
> The problem is that it's not specified wether (f)printf should issue
> only one I/O syscall or if it may issue several.
>
> printf("hello %s howdy?",name);
>
> could be implemented as:
>
> write(1,"hello %s howdy?",6);
> write(1,name,strlen(name));
> write(1,"hello %s howdy?"+8,7);
printf() does buffered writes, so the way
printf("hello %s howdy?",name);
writes to stdout is equivalent to:
putc('h');
putc('e');
putc('l');
...
putc('y');
putc('?');
If one of those putc() calls causes the stdout buffer to be filled
(and therefore flushed), it could block and subsequently fail with
EINTR.
> Then any EINTR could correspond to any of these write, and the client
> program couldn't know from which part of the format it should restart.
>
> Said otherwise, (f)printf must handle its own EINTR restarting.
No, (f)printf does not loop internally on EINTR. It will return -1
with errno=EINTR if interrupted. (Otherwise EINTR would not be
specified as an error condition for (f)printf.)
--
Geoff Clare <net...@gclare.org.uk>
Pascal Bourguignon
> No, (f)printf does not loop internally on EINTR. It will return -1
> with errno=EINTR if interrupted. (Otherwise EINTR would not be
> specified as an error condition for (f)printf.)
It is not:
Reformatting fprintf(3), please wait...
PRINTF(3) Linux Programmer's Manual PRINTF(3)
NAME
printf, fprintf, sprintf, snprintf, vprintf, vfprintf,
vsprintf, vsnprintf - formatted output conversion
SYNOPSIS
#include <stdio.h>
int printf(const char *format, ...);
int fprintf(FILE *stream, const char *format, ...);
int sprintf(char *str, const char *format, ...);
int snprintf(char *str, size_t size, const char *format,
...);
#include <stdarg.h>
int vprintf(const char *format, va_list ap);
int vfprintf(FILE *stream, const char *format, va_list
ap);
int vsprintf(char *str, const char *format, va_list ap);
int vsnprintf(char *str, size_t size, const char *format,
va_list ap);
DESCRIPTION
The functions in the printf family produce output accord
ing to a format as described below. The functions printf
and vprintf write output to stdout, the standard output
stream; fprintf and vfprintf write output to the given
output stream; sprintf, snprintf, vsprintf and vsnprintf
write to the character string str.
The functions vprintf, vfprintf, vsprintf, vsnprintf are
equivalent to the functions printf, fprintf, sprintf,
snprintf, respectively, except that they are called with a
va_list instead of a variable number of arguments. These
functions do not call the va_end macro. Consequently, the
value of ap is undefined after the call. The application
should call va_end(ap) itself afterwards.
These eight functions write the output under the control
of a format string that specifies how subsequent arguments
(or arguments accessed via the variable-length argument
facilities of stdarg(3)) are converted for output.
Return value
Upon successful return, these functions return the number
of characters printed (not including the trailing '\0'
used to end output to strings). The functions snprintf
and vsnprintf do not write more than size bytes (including
the trailing '\0'). If the output was truncated due to
this limit then the return value is the number of charac
ters (not including the trailing '\0') which would have
been written to the final string if enough space had been
available. Thus, a return value of size or more means that
the output was truncated. (See also below under NOTES.)
If an output error is encountered, a negative value is
returned.
Format of the format string
The format string is a character string, beginning and
ending in its initial shift state, if any. The format
string is composed of zero or more directives: ordinary
characters (not %), which are copied unchanged to the
output stream; and conversion specifications, each of
which results in fetching zero or more subsequent argu
ments. Each conversion specification is introduced by the
character %, and ends with a conversion specifier. In
between there may be (in this order) zero or more flags,
an optional minimum field width, an optional precision and
an optional length modifier.
The arguments must correspond properly (after type promo
tion) with the conversion specifier. By default, the argu
ments are used in the order given, where each `*' and each
conversion specifier asks for the next argument (and it is
an error if insufficiently many arguments are given). One
can also specify explicitly which argument is taken, at
each place where an argument is required, by writing `%m$'
instead of `%' and `*m$' instead of `*', where the decimal
integer m denotes the position in the argument list of the
desired argument, indexed starting from 1. Thus,
printf("%*d", width, num);
and
printf("%2$*1$d", width, num);
are equivalent. The second style allows repeated refer
ences to the same argument. The C99 standard does not
include the style using `$', which comes from the Single
Unix Specification. If the style using `$' is used, it
must be used throughout for all conversions taking an
argument and all width and precision arguments, but it may
be mixed with `%%' formats which do not consume an argu
ment. There may be no gaps in the numbers of arguments
specified using `$'; for example, if arguments 1 and 3 are
specified, argument 2 must also be specified somewhere in
the format string.
For some numeric conversions a radix character (`decimal
point') or thousands' grouping character is used. The
actual character used depends on the LC_NUMERIC part of
the locale. The POSIX locale uses `.' as radix character,
and does not have a grouping character. Thus,
printf("%'.2f", 1234567.89);
results in `1234567.89' in the POSIX locale, in
`1234567,89' in the nl_NL locale, and in `1.234.567,89' in
the da_DK locale.
The flag characters
The character % is followed by zero or more of the follow
ing flags:
# The value should be converted to an ``alternate
form''. For o conversions, the first character of
the output string is made zero (by prefixing a 0 if
it was not zero already). For x and X conversions,
a non-zero result has the string `0x' (or `0X' for
X conversions) prepended to it. For a, A, e, E, f,
F, g, and G conversions, the result will always
contain a decimal point, even if no digits follow
it (normally, a decimal point appears in the
results of those conversions only if a digit fol
lows). For g and G conversions, trailing zeros are
not removed from the result as they would otherwise
be. For other conversions, the result is unde
fined.
0 The value should be zero padded. For d, i, o, u,
x, X, a, A, e, E, f, F, g, and G conversions, the
converted value is padded on the left with zeros
rather than blanks. If the 0 and - flags both
appear, the 0 flag is ignored. If a precision is
given with a numeric conversion (d, i, o, u, x, and
X), the 0 flag is ignored. For other conversions,
the behavior is undefined.
- The converted value is to be left adjusted on the
field boundary. (The default is right justifica
tion.) Except for n conversions, the converted
value is padded on the right with blanks, rather
than on the left with blanks or zeros. A - over
rides a 0 if both are given.
' ' (a space) A blank should be left before a positive
number (or empty string) produced by a signed con
version.
+ A sign (+ or -) always be placed before a number
produced by a signed conversion. By default a sign
is used only for negative numbers. A + overrides a
space if both are used.
The five flag characters above are defined in the C stan
dard. The SUSv2 specifies one further flag character.
' For decimal conversion (i, d, u, f, F, g, G) the
output is to be grouped with thousands' grouping
characters if the locale information indicates any.
Note that many versions of gcc cannot parse this
option and will issue a warning. SUSv2 does not
include %'F.
glibc 2.2 adds one further flag character.
I For decimal integer conversion (i, d, u) the output
uses the locale's alternative output digits, if any
(for example, Arabic digits). However, it does not
include any locale definitions with such outdigits
defined.
The field width
An optional decimal digit string (with nonzero first
digit) specifying a minimum field width. If the converted
value has fewer characters than the field width, it will
be padded with spaces on the left (or right, if the left-
adjustment flag has been given). Instead of a decimal
digit string one may write `*' or `*m$' (for some decimal
integer m) to specify that the field width is given in the
next argument, or in the m-th argument, respectively,
which must be of type int. A negative field width is
taken as a `-' flag followed by a positive field width.
In no case does a non-existent or small field width cause
truncation of a field; if the result of a conversion is
wider than the field width, the field is expanded to con
tain the conversion result.
The precision
An optional precision, in the form of a period (`.') fol
lowed by an optional decimal digit string. Instead of a
decimal digit string one may write `*' or `*m$' (for some
decimal integer m) to specify that the precision is given
in the next argument, or in the m-th argument, respec
tively, which must be of type int. If the precision is
given as just `.', or the precision is negative, the pre
cision is taken to be zero. This gives the minimum number
of digits to appear for d, i, o, u, x, and X conversions,
the number of digits to appear after the radix character
for a, A, e, E, f, and F conversions, the maximum number
of significant digits for g and G conversions, or the max
imum number of characters to be printed from a string for
s and S conversions.
The length modifier
Here, `integer conversion' stands for d, i, o, u, x, or X
conversion.
hh A following integer conversion corresponds to a
signed char or unsigned char argument, or a follow
ing n conversion corresponds to a pointer to a
signed char argument.
h A following integer conversion corresponds to a
short int or unsigned short int argument, or a fol
lowing n conversion corresponds to a pointer to a
short int argument.
l (ell) A following integer conversion corresponds to
a long int or unsigned long int argument, or a fol
lowing n conversion corresponds to a pointer to a
long int argument, or a following c conversion cor
responds to a wint_t argument, or a following s
conversion corresponds to a pointer to wchar_t
argument.
ll (ell-ell). A following integer conversion corre
sponds to a long long int or unsigned long long int
argument, or a following n conversion corresponds
to a pointer to a long long int argument.
L A following a, A, e, E, f, F, g, or G conversion
corresponds to a long double argument. (C99 allows
%LF, but SUSv2 does not.)
q (`quad'. BSD 4.4 and Linux libc5 only. Don't use.)
This is a synonym for ll.
j A following integer conversion corresponds to an
intmax_t or uintmax_t argument.
z A following integer conversion corresponds to a
size_t or ssize_t argument. (Linux libc5 has Z with
this meaning. Don't use it.)
t A following integer conversion corresponds to a
ptrdiff_t argument.
The SUSv2 only knows about the length modifiers h (in hd,
hi, ho, hx, hX, hn) and l (in ld, li, lo, lx, lX, ln, lc,
ls) and L (in Le, LE, Lf, Lg, LG).
The conversion specifier
A character that specifies the type of conversion to be
applied. The conversion specifiers and their meanings
are:
d,i The int argument is converted to signed decimal
notation. The precision, if any, gives the minimum
number of digits that must appear; if the converted
value requires fewer digits, it is padded on the
left with zeros. The default precision is 1. When
0 is printed with an explicit precision 0, the out
put is empty.
o,u,x,X
The unsigned int argument is converted to unsigned
octal (o), unsigned decimal (u), or unsigned hex
adecimal (x and X) notation. The letters abcdef
are used for x conversions; the letters ABCDEF are
used for X conversions. The precision, if any,
gives the minimum number of digits that must
appear; if the converted value requires fewer dig
its, it is padded on the left with zeros. The
default precision is 1. When 0 is printed with an
explicit precision 0, the output is empty.
e,E The double argument is rounded and converted in the
style [-]d.ddde±dd where there is one digit before
the decimal-point character and the number of dig
its after it is equal to the precision; if the pre
cision is missing, it is taken as 6; if the preci
sion is zero, no decimal-point character appears.
An E conversion uses the letter E (rather than e)
to introduce the exponent. The exponent always
contains at least two digits; if the value is zero,
the exponent is 00.
f,F The double argument is rounded and converted to
decimal notation in the style [-]ddd.ddd, where the
number of digits after the decimal-point character
is equal to the precision specification. If the
precision is missing, it is taken as 6; if the pre
cision is explicitly zero, no decimal-point charac
ter appears. If a decimal point appears, at least
one digit appears before it.
(The SUSv2 does not know about F and says that
character string representations for infinity and
NaN may be made available. The C99 standard speci
fies `[-]inf' or `[-]infinity' for infinity, and a
string starting with `nan' for NaN, in the case of
f conversion, and `[-]INF' or `[-]INFINITY' or
`NAN*' in the case of F conversion.)
g,G The double argument is converted in style f or e
(or F or E for G conversions). The precision spec
ifies the number of significant digits. If the
precision is missing, 6 digits are given; if the
precision is zero, it is treated as 1. Style e is
used if the exponent from its conversion is less
than -4 or greater than or equal to the precision.
Trailing zeros are removed from the fractional part
of the result; a decimal point appears only if it
is followed by at least one digit.
a,A (C99; not in SUSv2) For a conversion, the double
argument is converted to hexadecimal notation
(using the letters abcdef) in the style
[-]0xh.hhhhp±d; for A conversion the prefix 0X, the
letters ABCDEF, and the exponent separator P is
used. There is one hexadecimal digit before the
decimal point, and the number of digits after it is
equal to the precision. The default precision suf
fices for an exact representation of the value if
an exact representation in base 2 exists and other
wise is sufficiently large to distinguish values of
type double. The digit before the decimal point is
unspecified for non-normalized numbers, and nonzero
but otherwise unspecified for normalized numbers.
c If no l modifier is present, the int argument is
converted to an unsigned char, and the resulting
character is written. If an l modifier is present,
the wint_t (wide character) argument is converted
to a multibyte sequence by a call to the wcrtomb
function, with a conversion state starting in the
initial state, and the resulting multibyte string
is written.
s If no l modifier is present: The const char * argu
ment is expected to be a pointer to an array of
character type (pointer to a string). Characters
from the array are written up to (but not includ
ing) a terminating NUL character; if a precision is
specified, no more than the number specified are
written. If a precision is given, no null charac
ter need be present; if the precision is not speci
fied, or is greater than the size of the array, the
array must contain a terminating NUL character.
If an l modifier is present: The const wchar_t *
argument is expected to be a pointer to an array of
wide characters. Wide characters from the array
are converted to multibyte characters (each by a
call to the wcrtomb function, with a conversion
state starting in the initial state before the
first wide character), up to and including a termi
nating null wide character. The resulting multibyte
characters are written up to (but not including)
the terminating null byte. If a precision is speci
fied, no more bytes than the number specified are
written, but no partial multibyte characters are
written. Note that the precision determines the
number of bytes written, not the number of wide
characters or screen positions. The array must
contain a terminating null wide character, unless a
precision is given and it is so small that the num
ber of bytes written exceeds it before the end of
the array is reached.
C (Not in C99, but in SUSv2.) Synonym for lc. Don't
use.
S (Not in C99, but in SUSv2.) Synonym for ls. Don't
use.
p The void * pointer argument is printed in hexadeci
mal (as if by %#x or %#lx).
n The number of characters written so far is stored
into the integer indicated by the int * (or vari
ant) pointer argument. No argument is converted.
% A `%' is written. No argument is converted. The
complete conversion specification is `%%'.
EXAMPLES
To print pi to five decimal places:
#include <math.h>
#include <stdio.h>
fprintf(stdout, "pi = %.5f\n", 4 * atan(1.0));
To print a date and time in the form `Sunday, July 3,
10:02', where weekday and month are pointers to strings:
#include <stdio.h>
fprintf(stdout, "%s, %s %d, %.2d:%.2d\n",
weekday, month, day, hour, min);
Many countries use the day-month-year order. Hence, an
internationalized version must be able to print the argu
ments in an order specified by the format:
#include <stdio.h>
fprintf(stdout, format,
weekday, month, day, hour, min);
where format depends on locale, and may permute the argu
ments. With the value
"%1$s, %3$d. %2$s, %4$d:%5$.2d\n"
one might obtain `Sonntag, 3. Juli, 10:02'.
To allocate a sufficiently large string and print into it
(code correct for both glibc 2.0 and glibc 2.1):
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
char *
make_message(const char *fmt, ...) {
/* Guess we need no more than 100 bytes. */
int n, size = 100;
char *p;
va_list ap;
if ((p = malloc (size)) == NULL)
return NULL;
while (1) {
/* Try to print in the allocated space. */
va_start(ap, fmt);
n = vsnprintf (p, size, fmt, ap);
va_end(ap);
/* If that worked, return the string. */
if (n > -1 && n < size)
return p;
/* Else try again with more space. */
if (n > -1) /* glibc 2.1 */
size = n+1; /* precisely what is needed */
else /* glibc 2.0 */
size *= 2; /* twice the old size */
if ((p = realloc (p, size)) == NULL)
return NULL;
}
}
NOTES
The glibc implementation of the functions snprintf and
vsnprintf conforms to the C99 standard, i.e., behaves as
described above, since glibc version 2.1. Until glibc
2.0.6 they would return -1 when the output was truncated.
CONFORMING TO
The fprintf, printf, sprintf, vprintf, vfprintf, and
vsprintf functions conform to ANSI X3.159-1989 (``ANSI
C'') and ISO/IEC 9899:1999 (``ISO C99''). The snprintf
and vsnprintf functions conform to ISO/IEC 9899:1999.
Concerning the return value of snprintf, the SUSv2 and the
C99 standard contradict each other: when snprintf is
called with size=0 then SUSv2 stipulates an unspecified
return value less than 1, while C99 allows str to be NULL
in this case, and gives the return value (as always) as
the number of characters that would have been written in
case the output string has been large enough.
Linux libc4 knows about the five C standard flags. It
knows about the length modifiers h,l,L, and the conver
sions cdeEfFgGinopsuxX, where F is a synonym for f. Addi
tionally, it accepts D,O,U as synonyms for ld,lo,lu.
(This is bad, and caused serious bugs later, when support
for %D disappeared.) No locale-dependent radix character,
no thousands' separator, no NaN or infinity, no %m$ and
*m$.
Linux libc5 knows about the five C standard flags and the
' flag, locale, %m$ and *m$. It knows about the length
modifiers h,l,L,Z,q, but accepts L and q both for long
doubles and for long long integers (this is a bug). It no
longer recognizes FDOU, but adds a new conversion charac
ter m, which outputs strerror(errno).
glibc 2.0 adds conversion characters C and S.
glibc 2.1 adds length modifiers hh,j,t,z and conversion
characters a,A.
glibc 2.2 adds the conversion character F with C99 seman
tics, and the flag character I.
HISTORY
Unix V7 defines the three routines printf, fprintf,
sprintf, and has the flag -, the width or precision *, the
length modifier l, and the conversions doxfegcsu, and also
D,O,U,X as synonyms for ld,lo,lu,lx. This is still true
for BSD 2.9.1, but BSD 2.10 has the flags #, + and <space>
and no longer mentions D,O,U,X. BSD 2.11 has vprintf,
vfprintf, vsprintf, and warns not to use D,O,U,X. BSD 4.3
Reno has the flag 0, the length modifiers h and L, and the
conversions n, p, E, G, X (with current meaning) and dep
recates D,O,U. BSD 4.4 introduces the functions snprintf
and vsnprintf, and the length modifier q. FreeBSD also
has functions asprintf and vasprintf, that allocate a
buffer large enough for sprintf. In glibc there are func
tions dprintf and vdprintf that print to a file descriptor
instead of a stream.
BUGS
Because sprintf and vsprintf assume an arbitrarily long
string, callers must be careful not to overflow the actual
space; this is often impossible to assure. Note that the
length of the strings produced is locale-dependent and
difficult to predict. Use snprintf and vsnprintf instead
(or asprintf and vasprintf).
Linux libc4.[45] does not have a snprintf, but provides a
libbsd that contains an snprintf equivalent to sprintf,
i.e., one that ignores the size argument. Thus, the use
of snprintf with early libc4 leads to serious security
problems.
Code such as printf(foo); often indicates a bug, since foo
may contain a % character. If foo comes from untrusted
user input, it may contain %n, causing the printf call to
write to memory and creating a security hole.
SEE ALSO
printf(1), asprintf(3), dprintf(3), wcrtomb(3),
wprintf(3), scanf(3), locale(5)
Linux Manpage 2000-10-16 PRINTF(3)
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best." -- Frank Zappa
Spoon
> Geoff Clare wrote:
>
>> No, (f)printf does not loop internally on EINTR. It will return -1
>> with errno=EINTR if interrupted. (Otherwise EINTR would not be
>> specified as an error condition for (f)printf.)
>
> It is not:
>
> Reformatting fprintf(3), please wait...
> PRINTF(3) Linux Programmer's Manual PRINTF(3)
I fear an old Linux man page doesn't qualify as an authoritative source.
:-)
http://www.opengroup.org/onlinepubs/007908799/xsh/fprintf.html
For the conditions under which fprintf() and printf() will fail and may
fail, refer to fputc() or fputwc().
http://www.opengroup.org/onlinepubs/007908799/xsh/fputc.html
ERRORS
The fputc() function will fail if either the stream is unbuffered
or the stream's buffer needs to be flushed, and:
[EINTR]
The write operation was terminated due to the receipt of a signal,
and no data was transferred.
Regards.
Pascal Bourguignon
I stand corrected. (f)printf are allowed to be useless...
To be POSIXly portable and correct, we should convert all our
(f)printf to snprintf+write...
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You question the worthiness of my code? I should kill you where you
stand!"
Ralf Fassel
| > [EINTR]
| > The write operation was terminated due to the receipt of a signal,
| > and no data was transferred.
| >
But doesn't the phrase 'no data was transferred' mean that 0 (zero)
bytes were written, so it would be safe to simply repeat the fprintf()
in case of EINTR?
R'
Spoon
However, I have NEVER seen fprintf() fail with errno=EINTR even when I
call fprintf() in a loop, and hammer it with signals:
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#define N 50000
#define R (4*N+4-12)
void foo(int sig) { }
int main(void)
{
int res;
FILE *fp = fopen("/dev/null", "w");
char *buf = malloc(N);
for (res=0; res < N; ++res)
buf[res] = 'a' + (res % 26);
signal(SIGINT, foo);
while ( 1 )
{
res = fprintf(fp, "%s %s %s %s\n", buf, buf+2, buf+4, buf+6);
if (res != R) break;
}
printf("ABOUT TO EXIT with res=%d\n", res);
return 0;
}
run ./a.out and in another shell run
while true; do kill -2 $A_PID; done
fprintf() never fails...
James Antill
> Hi,
>
> The Linux/POSIX man-page for (f)printf refers to fputc for conditions
> where printf may fail. When I look to fputc, it's said that fputc may
> fail with EINTR, interrupted by a signal.
>
> I thus imagine that fprintf may suddenly fail with EINTR in the midst
> of outputting its string.
>
> First question: is my assumption right ?
Yes, but that isn't something you worry about too much (a decent QOI).
There are a lot
of other errors that you can't avoid[1].
> Second question: if so, how can I recover from such condition ?
You can't, don't use stdio if you want reliable IO[2] it's standard, not
good. If you look at pretty much any unix source there will be no checks
of the return values on fprintf/printf/etc., that's because if you need to
check it you shouldn't be using it.
[1] The most obvious of which are ENOSPC, and EILSEQ[3].
[2] In theory, if you just use fread/fwrite and check everything[4] you
can make stdio work. I would highly recommend Vstr, for ease of separating
buffering and the actual IO calls.
[3] http://www.and.org/vstr/security#snprintf-ex1 ... this applies equally
to fprintf/printf but, again, you can't recover from it.
[4] Everything includes short writes, at which point you gain nothing over
write() but an extra copy QED.
--
James Antill -- ja...@and.org
http://www.and.org/and-httpd
Geoff Clare
> However, I have NEVER seen fprintf() fail with errno=EINTR even when I
> call fprintf() in a loop, and hammer it with signals:
>
[snip]
> signal(SIGINT, foo);
>
> while ( 1 )
> {
> res = fprintf(fp, "%s %s %s %s\n", buf, buf+2, buf+4, buf+6);
> if (res != R) break;
> }
Probably your signal() function is setting SA_RESTART. Try setting
up the signal handler with sigaction() and sa_flags = 0.
Even then it probably won't work because none of the write
operations are getting blocked. This works:
#include <signal.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
void foo(int sig) { }
static char buf[4096];
int main(void)
{
struct sigaction sa;
sa.sa_flags = 0;
sigemptyset(&sa.sa_mask);
sa.sa_handler = foo;
sigaction(SIGALRM, &sa, NULL);
fcntl(1, F_SETFL, O_NONBLOCK);
while (write(1, buf, sizeof buf) > 0)
;
while (write(1, buf, 1) == 1)
;
fprintf(stderr, "pipe is full\n");
fcntl(1, F_SETFL, 0);
for (;;)
{
alarm(2);
if (printf("foo") == -1)
perror("printf");
}
return 0;
}
$ ./a.out | sleep 10000
pipe is full
printf: Interrupted system call
printf: Interrupted system call
printf: Interrupted system call
printf: Interrupted system call
--
Geoff Clare <net...@gclare.org.uk>
Pascal Bourguignon
The problem is that output is buffered. If you fprintf 10KB, there
will be 10K cals to fputc, which will fill a 4KB buffer twice, so
write(2) will be called twice. You could get an EINTR at the first
write or at the second.
How do you know which?
How would you know what part of the format and what part of the data
to reformat to start from the second 4KB section?
What about the bytes that were still in the buffer before the fprintf?
How many of them there was? Perhaps 2K, and we'll have three write(2)?
It's impossible to know above the POSIX API, so it means that
(f)printf is useless: they shouldn't be used in programs that you want
to compile on platforms where (f)printf don't handle EINTR themselves.
racaille
> Then any EINTR could correspond to any of these write, and the client
> program couldn't know from which part of the format it should restart.
>
> Said otherwise, (f)printf must handle its own EINTR restarting.
do you know of any implementation where (f)printf (or stdio in general)
handles write(2) errors itself ?
that would be a gross layer violation (or whatever you may more
properly call it :)
Ralf Fassel
| > But doesn't the phrase 'no data was transferred' mean that 0
| > (zero) bytes were written, so it would be safe to simply repeat
| > the fprintf() in case of EINTR?
|
| The problem is that output is buffered. If you fprintf 10KB, there
| will be 10K cals to fputc, which will fill a 4KB buffer twice, so
| write(2) will be called twice. You could get an EINTR at the first
| write or at the second.
A naive expectation would be that once the first byte was handled, an
EINTR is no longer possible and must be handled by fprintf() itself.
Only _before_ the first byte was handled, an EINTR would be possible.
But maybe that would be too naive...
R'
Pascal Bourguignon
Indeed. fputc uses buffering, and EINTR is returned only by syscalls
such as write(2).
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
Bjorn Reese
> It's impossible to know above the POSIX API, so it means that
> (f)printf is useless: they shouldn't be used in programs that you want
> to compile on platforms where (f)printf don't handle EINTR themselves.
If you were to decide the behavior of (f)printf and EINTR, what would
you suggest that it should do?
Should it mask EINTR by retrying fputc/write until it succeeds? If so,
how do you interrupt (f)printf?
Should it mask EINTR by returning the number of characters successfully
written? If so, how do you indicate the interruption?
Should it return both EINTR and the number of characters successfully
written? If so, how do you combine the two?
--
mail1dotstofanetdotdk
Pascal Bourguignon
> Pascal Bourguignon wrote:
>
>> It's impossible to know above the POSIX API, so it means that
>> (f)printf is useless: they shouldn't be used in programs that you want
>> to compile on platforms where (f)printf don't handle EINTR themselves.
>
> If you were to decide the behavior of (f)printf and EINTR, what would
> you suggest that it should do?
>
> Should it mask EINTR by retrying fputc/write until it succeeds? If so,
> how do you interrupt (f)printf?
Not when in a syscall?
In anycase, what the signal handler does is irrelevant to how the
running process handles result codes from syscalls.
> Should it mask EINTR by returning the number of characters successfully
> written? If so, how do you indicate the interruption?
The process doesn't need and doesn't want to know when a signal
occured in a syscall, no more than it needs, wants and can know when
it occurs out of a syscall.
> Should it return both EINTR and the number of characters successfully
> written? If so, how do you combine the two?
No. (f)printf should do its job, print the characters and ensure
they're printed. If there's a signal handler that's call while print
works, be it during a syscall or out of a syscall, which exit(2), so
be it. If the program just wants to know that a signal occured, you
can write a signal handler that sets a global variable, and check when
this variable is set.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Bjorn Reese
> Not when in a syscall?
(f)printf are library calls, not system calls.
--
mail1dotstofanetdotdk
Pascal Bourguignon
> Pascal Bourguignon wrote:
>
>> Not when in a syscall?
>
> (f)printf are library calls, not system calls.
And what was the question I was answering to?
Quoting is an art, you cut too much!
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
ed
Pascal Bourguignon <p...@informatimago.com> wrote:
> > Should it mask EINTR by retrying fputc/write until it succeeds? If
> > so, how do you interrupt (f)printf?
>
> Not when in a syscall?
write is the syscall that (f)printf makes on the file descriptor.
--
Regards, Ed :: http://www.usenix.org.uk
just another perl person
:%s/Open Source/Free Software/g :: Free DNS available
Bjorn Reese
> Bjorn Reese <bre...@see.signature> writes:
>
>
>>Pascal Bourguignon wrote:
>>
>>
>>>Not when in a syscall?
>>
>>(f)printf are library calls, not system calls.
>
>
> And what was the question I was answering to?
The following:
>>If you were to decide the behavior of (f)printf and EINTR, what would
>>you suggest that it should do?
>>
>>Should it mask EINTR by retrying fputc/write until it succeeds? If so,
>>how do you interrupt (f)printf?
>
>
> Not when in a syscall?
>
--
mail1dotstofanetdotdk
Pascal Bourguignon
So, now, it should be clear what I meant:
You interrupt (f)printt when it is not in a syscall, don't you think?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay