{"id":2804,"date":"2017-12-16T00:01:33","date_gmt":"2017-12-16T08:01:33","guid":{"rendered":"http:\/\/c-for-dummies.com\/blog\/?p=2804"},"modified":"2017-12-18T21:05:27","modified_gmt":"2017-12-19T05:05:27","slug":"safe-coding-practices-getchar-and-putchar","status":"publish","type":"post","link":"https:\/\/c-for-dummies.com\/blog\/?p=2804","title":{"rendered":"Safe Coding Practices – getchar()<\/em> and putchar()<\/em>"},"content":{"rendered":"

I confess that I get sloppy with getchar()<\/em> and putchar()<\/em>. These are macros, not functions, but the issue is that their return value is an int<\/em>, not a char<\/em> variable. The reason why is important if you want to follow safe coding practices<\/a>.
\n
\nThe getchar()<\/em> and putchar()<\/em> functions return an int<\/em> is because they’re stream-oriented and can interact with files. Keyboard input provides char<\/em> values, but file input can generate int<\/em> values, such as the EOF<\/code> or End of File value, which is an int<\/em>. And file output can generate int<\/em> values on file errors. Safe coding practices dictate that you consider these conditions.<\/p>\n

The following code is a simple I\/O filter:<\/p>\n

\r\n#include <stdio.h>\r\n  \r\nint main()\r\n{\r\n    int ch;\r\n\r\n    while(1)\r\n    {\r\n        ch = getchar();\r\n        putchar(ch);\r\n    }\r\n\r\n    return(0);\r\n}<\/pre>\n
Both getchar()<\/em> and putchar()<\/em> use int<\/em> variable ch<\/code>, which is proper. If you run the program, you see everything input echoed back to output, as in:<\/p>\n
hello
\nhello<\/code><\/p>\n
If you type the EOF<\/code> character, however, you get unpredictable results. EOF<\/code> is Ctrl+D in most Unix shells, Ctrl+Z in Windows.<\/p>\n
Further, if you use the filter to pipe file input, you see all sorts of wackiness:<\/p>\n
cat file.txt | getputfilter<\/code><\/p>\n
Above, file.txt<\/code> is a text file and getputfilter<\/code> is the program compiled with the source code example. If file.txt<\/code> exists, the program doesn’t stop because the EOF<\/code> is never tested for in the code. If file.txt<\/code> doesn’t exist, the program does whatever as the non-existent file error isn’t captured. Obviously, the code needs improvements — it needs some safe coding practices implemented.<\/p>\n
First, to test for the EOF<\/code>, I modified the code as shown below:<\/p>\n
\r\n#include <stdio.h>\r\n  \r\nint main()\r\n{\r\n    int ch;\r\n\r\n    while(1)\r\n    {\r\n        ch = getchar();\r\n        if( ch == EOF)\r\n        {\r\n            if( ferror(stdin) )\r\n            {\r\n                puts(\"\\nEnd of File\");\r\n                clearerr(stdin);\r\n                return(0);\r\n            }\r\n        }\r\n        putchar(ch);\r\n    }\r\n\r\n    return(0);\r\n}<\/pre>\n
The if(ch==EOF)<\/code> statement tests for the EOF<\/code> character. When EOF<\/code> is encountered, the feof()<\/em> function confirms it, specifically for the stdin<\/em> “file.” If so, the text End of File<\/code> is output, the error is cleared for standard input, and the program terminates with a return<\/em> statement.<\/p>\n
After you make the changes and compile the code, the program accurately spies the EOF<\/code> character and doesn’t run amok.<\/p>\n
You can further bolster the code by using a ferror(stdin)<\/em> statement. Refer to my Lessons on the errno<\/code> variable<\/a> for more details on what you can do to further capture file I\/O errors for getchar()<\/em> and putchar()<\/em>.<\/p>\n
As with getchar()<\/em>, the putchar()<\/em> function can suffer from file errors as well, specifically with regards to redirected output that may go to an invalid file. I demonstrate an example in next week’s Lesson.<\/p>\n","protected":false},"excerpt":{"rendered":"
Beware the endless loop! Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-2804","post","type-post","status-publish","format-standard","hentry","category-main"],"_links":{"self":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2804","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2804"}],"version-history":[{"count":8,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2804\/revisions"}],"predecessor-version":[{"id":2885,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2804\/revisions\/2885"}],"wp:attachment":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2804"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2804"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2804"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}