On 2026-06-11 21:13, James Kuyper wrote:On 2026-06-11 14:12, Janis Papanagnou wrote:>On 2026-06-10 00:34, Keith Thompson wrote:...>For I/O, the equivalent of printf is a procedure. In C,>
printf("Hello, world\n") returns a negative result to denote an
error (and that value is often ignored).
Erm, I hope that above printf() call does not create an error, but
returns the number of characters in the printed text. ;-)
Hope is nice. I hope, in particular, that you're aware that there are
not guarantees on that matter?
Oh, actually I indeed thought that printing a constant string would not
create any error that would then be indicated by printf's return value.
Linux has a device called "/dev/full". It acts like it has no data
on input, and like it's full on output. You can redirect a program's
stdout to /dev/full. It's useful for testing, and much easier than
finding a writable filesystem with no remaining space. (/dev/null
accepts and discards as much intput as you send to it.)
On my system, a small write to /dev/full will typically succeed, since
the output is buffered rather than being immediately sent to the
file. It fails with ENOSPC after about 4 kbytes.
If I use fopen() to open /dev/full, then write to it, then fclose()
it, the fclose() fails. Since files are implicitly closed when
main() finishes, this is likely to go undetected.
A common pattern is "some_program > some_file", which redirects
stdout to a file but leaves stderr going to the default (typically
the tty).
I'd indeed also expected that, say, printing a string value with a '%d'
specifier would produce an error, but I saw that it doesn't; while the
compiler creates just a warning, execution provides some random output
and a _non-negative_ string-length value as printf's return value. Not
exactly what I'd expect from a language.
Calling printf with a mismatch between the format string and
an argument has undefined behavior. Some compilers will warn
about this in most cases, but in general the format string is not
necessarily known at compile time. No diagnostic or other error
indication is required.
Concerning the "guarantees" that you're asking for I sadly have to say
that I meanwhile expect nothing sensible at all any more from "C". ;-)
>
But to be more serious again...
>
The man-page is very unspecific on that; 'man 3 printf' says:
"If an output error is encountered, a negative value is returned."
>
Now of course an error can occur with that simple 'printf' above, for
example, by issuing an 'fclose (stdout);' before the 'printf (...);'
But what can I as a C-programmer derive from that; how would one act
on that. (That's just rhetorical.)
>
Obviously (because of that?) I've never seen anyone test such a call
by, say,
>
int rc = printf("Hello, world\n");
if (rc < 0) {
/* umm.. */
}
Quick-and-dirty programs like the classic "hello, world" often don't
bother to check. The above could print an error message to stderr and
call exit(EXIT_FAILURE). Even if stdout and stderr both produce errors,
the caller should be able to detect the error status. (I've configured
my shell to print a message when a program dies with an error status.)
But most production programs don't just blindly print stuff to stdout.
For example, GNU coreutils "cat" and "echo" both print "write error:
No space left on device" on stderr and exit with a status of 1 when
output is redirected to /dev/full -- if the output is big enough.
I haven't checked the source, but they must be explicitly checking
the result of both whatever output routine(s) they use and the
fclose(), or perhaps doing some fancy system-specific stuff that
has the same effect.
Are you - plural, all CLC audience - writing such code with 'printf()',
honestly? - Same question with 'int rc = fclose (...);' - what can one
do about that, then? (Write a logfile entry, maybe? - and then?)
Write the error message to stderr, optionally log it somewhere,
and exit with an error code.
But yes, I'm aware of negative OS function or library function output.
>
Our rules (back in my C/C++ days) suggested to catch any sensible and
possible error indications to quickly localize any potential issues.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Les messages affichés proviennent d'usenet.