{"id":2871,"date":"2017-12-23T00:01:44","date_gmt":"2017-12-23T08:01:44","guid":{"rendered":"http:\/\/c-for-dummies.com\/blog\/?p=2871"},"modified":"2017-12-16T09:40:54","modified_gmt":"2017-12-16T17:40:54","slug":"safe-coding-practices-putchar-as-a-loop-condition","status":"publish","type":"post","link":"https:\/\/c-for-dummies.com\/blog\/?p=2871","title":{"rendered":"Safe Coding Practices – putchar()<\/em> as a Loop Condition"},"content":{"rendered":"

It’s not unsafe to use putchar()<\/em> as condition inside a while<\/em> loop. If you dare try it, however, you must ensure that it checks for file errors. That’s an area where my own code often falls short.
\n
\nFrom last week’s Lesson<\/a>, I demonstrated various safe coding practices<\/a> for the getchar()<\/em> and putchar()<\/em> functions, most of which deal with the int<\/em> value returned from each function.<\/p>\n

Here is what I’m often guilty of doing in a while<\/em> loop (though this condition could also wiggle into a for<\/em> loop as well):<\/p>\n

\r\n#include <stdio.h>\r\n\r\nint main()\r\n{\r\n    char hello[] = \"Greetings, Human!\\n\";\r\n    char *s;\r\n\r\n    s = hello;\r\n    while(putchar(*s++))\r\n        ;\r\n\r\n    return(0);\r\n}<\/pre>\n
Pointer s<\/code> references the string hello<\/code>, which is output one character at a time as the while<\/em> loop’s condition.<\/p>\n
Most often I use the statement while(putchar(*s++));<\/code> as a demonstration of how C can be scrunched up or obfuscated. It’s a common example. The code expands to something more readable:<\/p>\n
\r\n    s = hello;\r\n    while( *s != '\\0' )\r\n    {\r\n        putchar(*s);\r\n        s++;\r\n    }<\/pre>\n
In my books and courses, I explain that *s!='\\0'<\/code> isn’t necessary because when *s<\/code> evaluates to the null character, the condition is interpreted as FALSE. Further you can combine the loop’s statements to putchar(*s++)<\/code>, then one thing becomes another, and soon the entire loop is its own condition.<\/p>\n
The *s!='\\0'<\/code> condition isn’t enough, however. That’s because putchar()<\/em> returns an int<\/em> value, which can also be the EOF<\/code> or a file error. The following update to the code accounts for these conditions:<\/p>\n
\r\n#include <stdio.h>\r\n  \r\nint main()\r\n{\r\n    char hello[] = \"Greetings, Human!\\n\";\r\n    char *s;\r\n    int out;\r\n\r\n    s = hello;\r\n    while( *s != '\\0' )\r\n    {\r\n        out = putchar(*s);\r\n        if( out==EOF || ferror(stdout) )\r\n        {\r\n            puts(\"\\nFile error\");\r\n            clearerr(stdout);\r\n            return(1);\r\n        }\r\n        s++;\r\n    }\r\n\r\n    return(0);\r\n}<\/pre>\n
To avoid having to cram too much into the while<\/em> loop’s condition, I placed the putchar()<\/em> statement into the loop itself. The value returned is saved in the out<\/code> variable. That return value is compared with the EOF<\/code>, along with the ferror()<\/em> value on the standard output device. When either situation occurs, an error message is displayed, the standard output device cleared of errors, and the program stops.<\/p>\n
This version of code is safer than the original because it handles any potential error output. (For details on handling file errors refer to this post<\/a>.) A problem I had with simulating such errors is that the shell catches most of them before the code has a chance to screw up. Still, if a file became corrupt after output redirection or some other disaster took place, the code would neatly exit, which is the entire point of safe coding practices.<\/p>\n","protected":false},"excerpt":{"rendered":"
It may seem unlikely, but the putchar()<\/em> function can return a file error. 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-2871","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\/2871","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=2871"}],"version-history":[{"count":5,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2871\/revisions"}],"predecessor-version":[{"id":2881,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2871\/revisions\/2881"}],"wp:attachment":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2871"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2871"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2871"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}