{"id":173,"date":"2013-07-20T00:01:52","date_gmt":"2013-07-20T08:01:52","guid":{"rendered":"http:\/\/c-for-dummies.com\/blog\/?p=173"},"modified":"2013-07-13T11:54:57","modified_gmt":"2013-07-13T19:54:57","slug":"what-is-true","status":"publish","type":"post","link":"https:\/\/c-for-dummies.com\/blog\/?p=173","title":{"rendered":"What is True?"},"content":{"rendered":"

True is a logical condition. It’s often written TRUE<\/code> just to confuse it with “true” which is a word that has other implications. But for programming, TRUE<\/code> generally means success. It’s the opposite of FALSE<\/code>, which generally means failure.
\n
\nTraditionally, FALSE<\/code> is assigned the value zero. That’s not a hard fact, but it’s often the case.<\/p>\n

When a function fails, it often returns zero. Or, more commonly, loops wind down from some number to zero, meaning that the loop has done or, specifically, the condition upon which the loop repeats is now FALSE<\/code>.<\/p>\n

TRUE<\/code>, on the other hand, is defined as non-zero. It could be the value 1, which it often is, but it could also be any other value that’s not zero. In fact, in many of my C programs, I’ll define TRUE<\/code> and FALSE<\/code> this way:<\/p>\n

#define FALSE 0
\n#define TRUE !FALSE<\/code><\/p>\n

So FALSE<\/code> is zero and TRUE<\/code> is “not FALSE<\/code>.” That way the compiler can figure out what the value of TRUE is and my code still works. This method also frees you from having to bind the value TRUE to something specific.<\/p>\n

As an example, suppose one compiler uses the value 0x0001 for TRUE<\/code> but another uses 0xFFFF for TRUE<\/code>. It happens. Or, more commonly, some function interprets any non-zero value as TRUE<\/code>. So 0x54 could be TRUE<\/code>, as could 0x52, 0x55, and 0x45.<\/p>\n

Here’s a chunk of code:<\/p>\n

\r\n#include <stdio.h>\r\n\r\n#define FALSE 0\r\n#define TRUE !FALSE\r\n\r\nint main()\r\n{\r\n    printf(\"True is %d\\n\",TRUE);\r\n    printf(\"False is %d\\n\",FALSE);\r\n\r\n    return(0);\r\n}<\/pre>\n
So how does the compiler calculate the value of TRUE<\/code>? Here’s the output:<\/p>\n
True is 1
\nFalse is 0<\/code><\/p>\n
That makes sense from a logical point of view, but also because the !<\/code> (bang or “not”) is a logical operator. The not<\/em> value of zero is one.<\/p>\n
Other ways to compute TRUE and FALSE also prove out those values:<\/p>\n
\r\n#include <stdio.h>\r\n\r\nint main()\r\n{\r\n    printf(\"True is %d\\n\",1==1);\r\n    printf(\"False is %d\\n\",1!=1);\r\n\r\n    return(0);\r\n}<\/pre>\n
In the above code, TRUE<\/code> and FALSE<\/code> aren’t declared as constants. They don’t have to be; the logical operations 1==1<\/code> and 1!=1<\/code> are used instead. The first operation is TRUE<\/code> and the second is FALSE<\/code>. The output is the same as for the first code:<\/p>\n
True is 1
\nFalse is 0<\/code><\/p>\n
The only exception I can find to the TRUE<\/code> is 1 and FALSE<\/code> is 0 paradigm is the return value passed to the operating system. In that case, zero has traditionally indicated a successful completion and any other value indicates some other condition.<\/p>\n
The return code zero as TRUE<\/code> makes sense if you read the value returned as an “error level” instead of a success: Returning zero indicates a FALSE<\/code>, or no error. That’s my explanation, although I’d be interested in the history behind the return code to discover the real reason.<\/p>\n","protected":false},"excerpt":{"rendered":"
The basic concepts of TRUE<\/code> and FALSE<\/code> mean more than just 1 or 0 — if they even mean that at all! 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-173","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\/173","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=173"}],"version-history":[{"count":6,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/173\/revisions"}],"predecessor-version":[{"id":182,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/173\/revisions\/182"}],"wp:attachment":[{"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=173"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=173"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/c-for-dummies.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=173"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}