From: Keith Thompson <kst@king.cts.com>
Subject: Re: Boolean Representation
Date: 1998/09/26
Date: 1998-09-26T00:00:00+00:00 [thread overview]
Message-ID: <yec1zoyd2xa.fsf@king.cts.com> (raw)
In-Reply-To: Ezw8Et.57H.0.-s@inmet.camb.inmet.com
stt@houdini.camb.inmet.com (Tucker Taft) writes:
> It is just this kind of thinking which led people to put "reconfirming"
> representation clauses on enumeration types in Ada 83. What a waste
> of energy! We added a rule in Ada 95 to save the paranoid from
> writing all those silly enumeration representation clauses. I can
> see we should have gone one step further, specifying the representation
> for 1-bit boolean objects. Groan.
I really didn't mean to induce paranoia, and I agree it's not worth
worrying about in the real world.
> Please paranoid readers, don't go worrying about the possibility of
> 1-bit boolean objects having False = 1. Instead, let's all agree
> to shun any Ada compiler which makes such an absurd choice... That's
> ultimately much more effective than any words in a standard.
Fortunately, I seriously doubt that there will ever be any such
compilers to shun.
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.
Fortunately Ada tends to make the need for such assumptions rare.
(Sorry, I've been programming in C lately. I guess it's warped my
mind a bit.)
--
Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*>
Qualcomm, San Diego, California, USA <http://www.qualcomm.com>
It takes a Viking to raze a village.
next prev parent reply other threads:[~1998-09-26 0:00 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-09-24 0:00 Boolean Representation matthew_snyder
1998-09-24 0:00 ` dewarr
1998-09-24 0:00 ` matthew_snyder
1998-09-24 0:00 ` Tom Moran
1998-09-25 0:00 ` dewarr
1998-09-25 0:00 ` Tom Moran
1998-09-24 0:00 ` dennison
1998-09-25 0:00 ` Robert I. Eachus
1998-09-25 0:00 ` dewarr
1998-09-24 0:00 ` Samuel T. Harris
1998-09-25 0:00 ` dewarr
1998-09-27 0:00 ` Samuel T. Harris
1998-09-28 0:00 ` dewar
1998-09-24 0:00 ` dennison
1998-09-24 0:00 ` Keith Thompson
1998-09-25 0:00 ` dennison
1998-09-25 0:00 ` Keith Thompson
1998-09-26 0:00 ` Tucker Taft
1998-09-26 0:00 ` Keith Thompson [this message]
1998-09-27 0:00 ` dewarr
1998-09-27 0:00 ` null pointer representation (was: Boolean Representation) Arthur Evans Jr
1998-09-27 0:00 ` Keith Thompson
1998-09-28 0:00 ` dewarr
1998-09-28 0:00 ` Keith Thompson
1998-09-28 0:00 ` dewarr
1998-09-30 0:00 ` Keith Thompson
1998-10-02 0:00 ` Robert I. Eachus
1998-09-28 0:00 ` Lieven Marchand
1998-09-27 0:00 ` Boolean Representation dewarr
-- strict thread matches above, loose matches on Subject: below --
1998-09-24 0:00 matthew_snyder
1998-09-25 0:00 ` Tucker Taft
1998-09-25 0:00 ` dewarr
1998-09-25 0:00 ` dewarr
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox