{"id":282,"date":"2013-09-14T00:01:05","date_gmt":"2013-09-14T08:01:05","guid":{"rendered":"http:\/\/c-for-dummies.com\/blog\/?p=282"},"modified":"2013-09-07T07:19:36","modified_gmt":"2013-09-07T15:19:36","slug":"conversion-character-abuse","status":"publish","type":"post","link":"https:\/\/c-for-dummies.com\/blog\/?p=282","title":{"rendered":"Conversion Character Abuse"},"content":{"rendered":"

The printf()<\/em> function is most concerned with getting the number of conversion characters — the %<\/code> placeholders — to match the number of variables specified. Beyond that, it’s rather ambivalent as to whether the types match properly.
\n
\nLast week’s blog lesson<\/a> discussed the virtues of signed<\/em> and unsigned<\/em> variable types, specifically with regards to how information is stored in memory. The compiler treats both types differently, but the information in memory is unaffected by how the compiler — and the running program — see the value.<\/p>\n

Yeah, this is weird, but as long as you mind your signed<\/em> and unsigned<\/em> variable types in the code, you’ll be okay.<\/p>\n

What gets even weirder is when the printf()<\/em> conversion characters come into play.<\/p>\n

If you’ve read my books or worked some of the examples on this web site, you’ve seen me occasionally use the %d<\/code> placeholder in a printf()<\/em> statement to display a char<\/em> value. You’d expect to use the %c<\/code> placeholder, which displays the character represented by the stored value. When you use %d<\/code>, however, you see the character’s code value, which is closer to the information actually stored in memory.<\/p>\n

The conversion characters are merely interpreters.<\/p>\n

Consider the following code:<\/p>\n

\r\n#include <stdio.h>\r\n\r\nint main()\r\n{\r\n    char c = 0x40;\r\n\r\n    printf(\"%c\\n\",c);\r\n    printf(\"%d\\n\",c);\r\n    printf(\"%u\\n\",c);\r\n\r\n    return(0);\r\n}<\/pre>\n
In the code, the char<\/em> variable c<\/code> is displayed by using three different conversion characters: %c<\/code> shows the result as a character, %d<\/code> shows the result as a signed int<\/em> value, and %u<\/code> shows the result as an unsigned int<\/em> value. The code compiles without any warnings or errors.<\/p>\n
Of course, it’s not a conversion character free-for-all in the printf()<\/em> function. If you add another line to the code:<\/p>\n
printf(\"%s\\n\",c);<\/code><\/p>\n
You see a compiler warning displayed about mismatched types, specifically that variable c<\/code> is not a pointer. The compiler is very concerned about pointer (and therefore string) errors because they deal with memory locations. The operating system jealously protects memory. Running the code after such a warning most likely generates a segmentation fault or other hideous error.<\/p>\n
Beyond pointers, the use of the proper conversion character in printf()<\/em> is pretty much up to interpretation, which brings me to the puzzle presented in last week’s lesson:<\/p>\n
140\t4294967180\r\n141\t4294967181\r\n142\t4294967182\r\n143\t4294967183<\/code><\/pre>\n
When you use the %u<\/code> placeholder on an signed<\/em> variable, the results are not open to interpretation: They’re wrong.<\/p>\n
Here’s the code that generated the above output:<\/p>\n
\r\n#include <stdio.h>\r\n\r\nint main()\r\n{\r\n    unsigned char a;\r\n    signed char b;\r\n    int x;\r\n\r\n    a = b = 0;\r\n    for(x=0;x<400;x++)\r\n    {\r\n        printf(\"%3d\\t%3u\\n\",a,b);\r\n        a++; b++;\r\n    }\r\n    return(0);\r\n}<\/pre>\n
Variable b<\/code> is declared as a signed<\/em> value. It can be positive or negative. When the %u<\/code> (or in the code, %3u<\/code>) placeholder is used, the signed<\/em> value stored is interpreted as unsigned<\/em>. The same value is stored in variable a<\/code>, an unsigned char<\/em> variable. So how does the computer make 4294967183 out of 143?<\/p>\n
Before unraveling that riddle, remember that the range of a signed char<\/em> variable is from -128 through 127. Because b<\/code> is declared as signed<\/em>, any value over 127 placed into that storage container is interpreted as negative. Variable a<\/code> sees the value as positive. So when unsigned<\/em> a<\/code> is 128, signed<\/em> b<\/code> is -128. Likewise, when signed<\/em> a<\/code> is 255, unsigned<\/em> b<\/code> is -1. Then both values “roll over” to zero. (Review the output from last week’s blog post<\/a> for a visual example.)<\/p>\n
If you can fathom that concept, then what would make sense would be for the %u<\/code> placeholder merely to convert the value -128 to 128 for both variables a<\/code> and b<\/code>. That’s not what happens, of course.<\/p>\n
The reason for output going to 4294967183 is that the compiler (at least my compiler) uses four bytes to store a char<\/em> value. When the improper conversion character is used, the printf()<\/em> function sees all four bytes of storage in memory, not a char<\/em> variable, and the resulting output looks screwy.<\/p>\n
Bottom line: Although you can get away with substituting conversion characters for some variable types, and such substitution can be put to good use, be careful! When you get weird output, double-check that the types match.<\/p>\n","protected":false},"excerpt":{"rendered":"
The C language’s rather carefree way of dealing with variables can bring up some interesting puzzles regarding the printf()<\/em> function’s use of conversion characters. 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-282","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\/282","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=282"}],"version-history":[{"count":5,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/282\/revisions"}],"predecessor-version":[{"id":287,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/282\/revisions\/287"}],"wp:attachment":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=282"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=282"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=282"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}