{"id":724,"date":"2014-05-31T00:01:31","date_gmt":"2014-05-31T07:01:31","guid":{"rendered":"http:\/\/c-for-dummies.com\/blog\/?p=724"},"modified":"2014-05-24T08:12:35","modified_gmt":"2014-05-24T15:12:35","slug":"word-wrap-filter-repair","status":"publish","type":"post","link":"https:\/\/c-for-dummies.com\/blog\/?p=724","title":{"rendered":"Word Wrap Filter Repair"},"content":{"rendered":"

As a programmer, always be thinking: What can go wrong? What would be an exception? Where have I made assumptions? You can’t avoid bugs by making such challenges, but you can diminish their possibilities.
\n
\nA case in point is the word wrap filter, presented in last week’s Lesson<\/a>. As I pointed out, that code has two major flaws. These are discovered either through extensive testing or by reviewing the code in your noggin and trying to figure out ways to break it.<\/p>\n

The first flaw occurs when a newline is encountered in the buffer, before the wrapping point. In that case, you can end up with filter output that looks jagged and sloppy:<\/p>\n

He has\r\nabdicated Government here, by declaring\r\nus out of his Protection and waging War\r\nagainst us.\r\nHe has plundered our seas,\r\nravaged our Coasts, burnt our towns, and\r\ndestroyed the lives of our people.\r\nHe is\r\nat this time transporting large Armies<\/code><\/pre>\n
Instead of:<\/p>\n
He has abdicated Government here, by\r\ndeclaring us out of his Protection and\r\nwaging War against us.\r\nHe has plundered our seas, ravaged our\r\nCoasts, burnt our towns, and destroyed\r\nthe lives of our people.\r\nHe is at this time transporting large\r\nArmies<\/code><\/pre>\n
The second flaw happens when no whitespace characters are encountered before the right margin. In that case, the code would overflow and you might see one of those notorious Segmentation Fault errors.<\/p>\n
One fix at a time!<\/p>\n
To deal with a newline character encountered before the right_margin<\/code>, the following code can be added after Line 31. That’s where the character received is placed into the buffer<\/code>.<\/p>\n
\r\n \t\t\/* check for newline before margin *\/<\/span>\r\n \t\tif(*space == '\\n')\r\n \t\t{\r\n \t\t\t*space = '\\0';\r\n \t\t\tx = 0;\r\n \t\t\twhile(*(buffer+x))\r\n \t\t\t{\r\n \t\t\t\tif( *(buffer+x)==EOF)\r\n \t\t\t\t\texit(0);\r\n \t\t\t\tputchar(*(buffer+x));\r\n \t\t\t\tx++;\r\n \t\t\t}\r\n \t\t\tputchar('\\n');\r\n \t\t\tposition=0;\r\n \t\t}<\/pre>\n
When a newline is encountered, the buffer<\/code> is immediately capped with a null character, \\0<\/code>. Then the buffer is displayed, again confirming that an EOF<\/em> isn’t lurking somewhere. The program then continues looking for input.<\/p>\n
Click here<\/a> to view the full version of this code.<\/p>\n
The fix to determine whether any whitespace character was encountered — such as when a very, very long word appears in the text — is more extensive: It involves a structural change the program. That’s because when no place to wrap exists, then the text must be output as one chunk, without wrapping. That may not be the best way to handle such a situation, but it’s my choice as programmer.<\/p>\n
In the original code, a decision must be made when the position<\/code> pointer passes the right_margin<\/code>, indicating that the buffer<\/code> is full and word wrap is necessary:<\/p>\n
\r\n        \/* check to see if the margin has been reached *\/<\/span>\r\n        if(position > right_margin)\r\n        {\r\n            \/* Check to see whether any words found *\/<\/span>\r\n            if(buffer == space)<\/pre>\n
The if<\/em> test above determines whether the space<\/code> pointer has moved forward or not. If not, then the buffer<\/code> contains one huge word that cannot be wrapped. Therefore the statements belonging to if<\/em> merely display the text-chunk, no wrapping:<\/p>\n
\r\n            if(buffer == space)\r\n            {\r\n                for(x=0;x<right_margin;x++)\r\n                {\r\n                    if( *(buffer+x)==EOF)\r\n                        exit(0);\r\n                    putchar(*(buffer+x));\r\n                }\r\n                *buffer = *(buffer+x);\r\n                position=1;\r\n            }<\/pre>\n
This code spits out the buffer<\/code>‘s contents to standard output. If an EOF<\/em> is encountered, then output terminates and the program quits with an exit()<\/em> function. Otherwise, the final character in the buffer<\/code> is copied back to the start, so that the process can continue.<\/p>\n
An else<\/em> follows the if<\/em> test. Its statements basically process the buffer<\/code>, displaying characters up until the space<\/code> pointer, as was shown in the original code.<\/p>\n
Click here<\/a> to view the final version of the word wrap filter.<\/p>\n
Is this filter perfect? I dunno.<\/p>\n
I’m not being silly: On your own you can guess which parts of the code might fail or you can experiment on a variety of interesting situations. My goal is not to create perfect code as much as I want to create well-running code. If it needs to be fixed later, then that’s part of the process. The better you can anticipate problems and bugs, and the more elegant your code, the better it is to fix problems in the future.<\/p>\n","protected":false},"excerpt":{"rendered":"
As a programmer, you need to be constantly on the lookout for code that may not work as intended. 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-724","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\/724","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=724"}],"version-history":[{"count":5,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/724\/revisions"}],"predecessor-version":[{"id":745,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/724\/revisions\/745"}],"wp:attachment":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=724"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=724"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=724"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}