will 'printf' always do its job?

printf("/*something else*/"); /*note that:without using \n in printf*/

I know pri开发者_StackOverflowntf() uses a buffer which prints whatever it contains when, in the line buffer, "\n" is seen by the buffer function. So when we forget to use "\n" in printf(), rarely, line buffer will not be emptied. Therefore, printf() wont do its job. Am I wrong?

The example you gave above is safe as there are no variable arguments to printf. However it is possible to specify a format string and supply variables that do not match up with the format, which can deliver unexpected (and unsafe) results. Some compilers are taking a more proactive approach with printf use case analysis, but even then one should be very, very careful when printf is used.

From my man page:

These functions return the number of characters printed (not including the trailing \0 used to end output to strings) or a negative value if an output error occurs, except for snprintf() and vsnprintf(), which return the number of characters that would have been printed if the n were unlimited (again, not including the final \0).

So, it sounds like the can fail with a negative error.

Yes, output to stdout in C (using printf) is normally line buffered. This means that printf() will collect output until either:

• the buffer is full, or
• the output contains a \n newline

If you want to force the output of the buffer, call fflush(stdout). This will work even if you have printed something without a newline.

Also printf and friends can fail.

Common implementations of C call malloc() in the printf family of the stdC library.
malloc can fail, so then will printf. In UNIX the write() call can be interrupted by EINTR, so context switching in UNIX will trigger faults (EINTR). Windows can and will do similar things.

And... Although you do not see it posted here often you should always check the return code from any system or library function that returns a value.

Like that, no. It won't always work as you expect, especially if you're using user input as the format string. If the first argument has %s or %d or other format specifiers in it, they will be parsed and replaced with values from the stack, which can easily break if it's expecting a pointer and gets an int instead.

This way tends to be a lot safer:

printf("%s", "....");

The output buffer will be flushed before exit, or before you get input, so the data will make it regardless of whether you send a \n.

printf could fail for any number of reasons. If you're deep in recursion, calling printf may blow your stack. The C and C++ standards have little to say on threading issues and calling printf while printf is executing in another thread may fail. It could fail because stdout is attached to a file and you just filled your filesystem, in which case the return value tells you there was a problem. If you call printf with a string that isn't zero terminated then bad things could happen. And printf can apparently fail if you're using buffered I/O and your buffer hasn't been flushed yet.