Re: Boolean Representation

[dewarr@my-dejanews.com]

In article <yec1zoyd2xa.fsf@king.cts.com>,
  Keith Thompson <kst@king.cts.com> wrote:
> Sometimes, however, it's not 100% obvious which assumptions one should
> make.  We can safely assume that a 1-bit Boolean uses (False => 0,
> True => 1), even though it's not spelled out in the RM.  We *can't*
> safely assume that an 8-bit (or 32-bit, or whatever) Boolean uses
> (False => 0, True => 1) -- though we can *probably* assume that False
> is 0.  Nor can we assume that a program exit status of 0 denotes
> success and 1 denotes failure, or that a floating-point 0.0 or a null
> pointer is represented as all-bits-zero, or that record components are
> laid out in the order in which they're declared -- though some
> programmers will insist on doing so.

No! That is going too far in the other direction, the 95 RM goes out of its
way to tell you that you CANNOT *probably* assume this. You may assume nothing
about the representaiton of Boolean, other than that it is ordered, considered
either signed or as unsigned. For example, some safety critical implementation
might use 0101 for False, and 1010 for True (see Brian Wichman's discussion
of the advantages of this representation). Such a representation is just fine,
and assuming that False is zero for other than a 1-bit representation (where
there is no other reasonable choice), would be incorrect.

It is not always easy to understand the boundary between what is reasonable
and unreasonable, but I think it is easy enough in this case. Yes, I know
that some formalist might claim:

 False = -1  True = 0

with a 1-bit twos complement representation, and indeed that shows that an
AI probably *is* needed for formal reasons, but one cannot imagine a compiler
choosing this.

One can however, most certainly imagine a compiler that generates junk code
for a "confirming" enum rep clause. Certainly not all compilers make this
mistake (GNAT most certainly does not), but we have read here of real Ada 95
compilers that do make this mistake, so the best pragmatic approach is most
certainly to avoid junk confirming rep clauses.

Note that you may or may not be able to define a derived boolean and give
a rep clause for it, that is non-portable impl-dependent coding.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum