Oh, I could have fun with the term “standard error device.” It could be any PCs running Windows 8. [rimshot] See? Tech humor! It’s nerdy, but that’s not the point of the standard error device with regards to C programming.
\n
\nIn C, as well as other programming languages, three standard I\/O devices are available:<\/p>\n
The The When you use any of C standard I\/O library functions, they default to This code generates three lines of text. The printf()<\/em> statement uses the This code is identical to the following:<\/p>\n In this example, the fprintf()<\/em> function replaces printf()<\/em>. It requires a stream argument before the format string, which can be the handle of an open file or one of the standard I\/O devices. In C, In the next example, I changed the second fprintf()<\/em> statement to use the Again, the output is the same, but unlike Above, the program (named In my code, I use the Because I\/O in C is buffered, it’s common that an error message sent to Sending errors to the standard error device is useful, but it’s not without its quirks. Continue reading stdin<\/code> for standard input
\nstdout<\/code> for standard output
\nstderr<\/code> for error message output<\/p>\nstdin<\/code> and stdout<\/code> devices are traditionally mapped to the keyboard and screen, respectively. In the olden days, these devices were a teletype. Anyway, input and output from these devices can be redirected. Input can flow from a file, for example, and output can be sent to a file or to another program, where it becomes standard input.<\/p>\nstderr<\/code> device cannot be redirected. It’s always mapped to the same gizmo, which on modern computers is the terminal window. This device generates error messages or other text a programmer wants displayed and not sent elsewhere.<\/p>\nstdin<\/code> and stdout<\/code> for input and output:<\/p>\n\r\n#include <stdio.h>\r\n\r\nint main()\r\n{\r\n printf(\"Here is Line 1\\n\");\r\n printf(\"Here is Line 2\\n\");\r\n printf(\"Here is Line 3\\n\");\r\n\r\n return(0);\r\n}<\/pre>\nstdout<\/code> device by default. Here’s the sample run:<\/p>\nHere is Line 1\r\nHere is Line 2\r\nHere is Line 3<\/code><\/pre>\n\r\n#include <stdio.h>\r\n\r\nint main()\r\n{\r\n fprintf(stdout,\"Here is Line 1\\n\");\r\n fprintf(stdout,\"Here is Line 2\\n\");\r\n fprintf(stdout,\"Here is Line 3\\n\");\r\n\r\n return(0);\r\n}<\/pre>\nstdout<\/code> is accepted as a stream argument, always open for every program you run, as are stdin<\/code> and stderr<\/code>. So in this example, the strings are sent to the “file” stdout<\/code>. The code’s output is the same.<\/p>\nstderr<\/code> output device instead of stdout<\/code>:<\/p>\n\r\n#include <stdio.h>\r\n\r\nint main()\r\n{\r\n fprintf(stdout,\"Here is Line 1\\n\");\r\n fprintf(stderr,\"Here is Line 2\\n\");\r\n fprintf(stdout,\"Here is Line 3\\n\");\r\n\r\n return(0);\r\n}<\/pre>\nstdout<\/code>, stderr<\/code> output cannot be redirected to another device. When I run the code in a terminal window and redirect the output elsewhere, I see only the text generated by the second fprintf()<\/em> statement:<\/p>\n$ .\/a.out > \/dev\/null \r\nHere is Line 2<\/code><\/pre>\na.out<\/code>) sent output the \/dev\/null<\/code> device, which is a “door to nowhere” in the Unix operating system. (In Windows, use > nul<\/code>.) The first and third fprintf()<\/em> statement’s output meanders off in to the null<\/code> device, but because the second fprintf()<\/em> statement sends it output to stderr<\/code>, it shows up in the terminal window.<\/p>\nstderr<\/code> device to output error messages. Especially for programs I write where I know the output is immediately fed into another program, it’s important that I see those error messages directly. Output to stderr<\/code> guarantees that they show up, but the output isn’t without its quirks.<\/p>\nstderr<\/code> appears out of sequence with other text sent to standard output. I tried to replicate this peculiarity with a sample program, but it takes too much code to make it work consistently. Still, it’s possible for an error message to show up earlier than other text sent to (buffered) standard output. That weird sequencing bugged me, but it’s something you must understand when you use stderr<\/code> to generate error output.<\/p>\n","protected":false},"excerpt":{"rendered":"