{"id":2597,"date":"2017-03-17T06:56:24","date_gmt":"2017-03-16T18:56:24","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=2597"},"modified":"2017-03-17T07:50:48","modified_gmt":"2017-03-16T19:50:48","slug":"true-1-and-true-1","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/2597\/","title":{"rendered":"(True = 1) and (True = ‘-1’) ?"},"content":{"rendered":"[Estimated Reading Time: <\/span> 4<\/span> minutes]<\/span><\/span>

It has been observed that the Delphi documentation states<\/a> that the constants True<\/strong> and False <\/strong>have the values 1<\/strong> and 0<\/strong> respectively, not the -1<\/strong> and 0<\/strong> that the default string conversions apply. This does actually make sense but also lays a trap for the unwary.<\/p>\n

<\/p>\n

True, True, Wherefore Art Thou ‘-1’ ? <\/h2>\n

In the Simple Types documentation<\/a> it is stated that any non-zero value<\/em> is logically true. But in the documentation for the Boolean type itself<\/a> it is stated that only ordinal value 1<\/em> is considered true.<\/p>\n

But if True<\/strong> has the explicit<\/em> value 1<\/strong> why does BoolToStr(True)<\/strong> return ‘-1’<\/strong> and not simply ‘1’<\/strong> ?<\/p>\n

Well, in one key respect the documentation for the Boolean<\/strong> type is simply wrong.<\/p>\n

In fact, any non-zero value<\/em> is logically<\/em> true, not just 1. i.e. the Simple Types<\/strong> documentation is correct on this point, as we can easily demonstrate:<\/p>\n

\r\n   procedure TestBoolean;\r\n   var\r\n     b: Boolean;\r\n   begin\r\n     b := Boolean(42);\r\n\r\n     if b then\r\n       ShowMessage('42 is True!');\r\n   end;\r\n<\/pre>\n
Run this and you will<\/em> see the message.<\/p>\n
And this leads us to an understanding of why BoolToStr(True)<\/strong> might reasonably return ‘-1’<\/strong>.<\/p>\n
Regardless of the specific size of Boolean<\/strong> type involved (Byte, Word, Long etc), any non-zero value must have at least<\/em> one bit set and may have more<\/em> than one bit set.  So it makes a certain amount of sense to say that a logical True<\/strong> is equivalent to a value where all<\/strong> possible bits are set, since any of them could<\/em> be for any particular logically true value.<\/p>\n
And in Two’s Complement<\/a> notation, an integer with all bits set has the value -1.<\/strong><\/p>\n
That’s one way to think about it.  But the Two’s Complement rationale also applies when considering Booleans as strictly, well, Boolean.  \ud83d\ude42<\/p>\n
False<\/strong> has ordinality 0<\/strong> and since True<\/strong> is the logical negation<\/em> of False<\/strong> then if we flip all the bits in any sized value of False<\/strong> (0) then we again end up with all bits set which in Two’s Complement again yields -1<\/strong>.<\/p>\n
Ta-dah!<\/p>\n
 A Question for the Ages… <\/h2>\n
Perhaps the real question is why True<\/strong> was ever defined with ordinality of 1<\/strong> in the first place, and not -1<\/strong> ?<\/p>\n
I honestly don’t know, but suspect that it likely goes back to the origins of Pascal in the 1970’s and the introduction of Boolean as a formal enumerated type, thus determining the ordinality of the members as 0 and 1.<\/p>\n
This might also explain some of the enum-like capabilities\/compatibility of Boolean<\/strong> in Delphi, whilst clearly not behaving as an enum in some key respects.<\/p>\n
The similarities:<\/p>\n