Boolean Representation

Boolean Representation

[matthew_snyder]

Is it safe to make the assumption that a boolean value of FALSE will always
be represented as a 0 and a value of TRUE will always be represented as a 1? 
Will an unchecked conversion from a boolean to an integer always yield the
same results with different compilers?

Matthew Snyder
matthew_snyder@hotmail.com

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

Re: Boolean Representation

[dewarr]

In article <6udkcj$87j$1@nnrp1.dejanews.com>,
  matthew_snyder@my-dejanews.com wrote:
> Is it safe to make the assumption that a boolean value of FALSE will always
> be represented as a 0 and a value of TRUE will always be represented as a 1?
> Will an unchecked conversion from a boolean to an integer always yield the
> same results with different compilers?


Whether true or false, this is junky coding, just use
Boolean'Pos (val) to get 0 or 1 in a for sure portable
manner. Remember that to use an unchecked conversion for
Boolean, you would have to use a 1-bit integer, anything
else most definitely gives an implementation defined result.

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

Re: Boolean Representation

[matthew_snyder]

The reason for my original question is that I'm trying to decide the best
(most portable) way to convert an UNSIGNED_8 to a record type which provides
access to the individual bits.	The record could either consist of booleans,
or it could consist of my own bit type (is there a predefined BIT type that
I'm overlooking?).  Right now my record consists of booleans and I'm
performing an unchecked conversion from UNSIGNED_8 to the record type.	The
option of doing a "for RECORD'ADDRESS use SOME_ADDRESS" is not available in
this situation. Is any use of UNCHECKED_CONVERSION considered "junky coding"?
 I certainly would not want to have to do a 'POS on every bit to assure
portability.  What's the best way to do this?


In article <6udriu$hfi$1@nnrp1.dejanews.com>,
  dewarr@my-dejanews.com wrote:
> In article <6udkcj$87j$1@nnrp1.dejanews.com>,
>   matthew_snyder@my-dejanews.com wrote:
> > Is it safe to make the assumption that a boolean value of FALSE will always
> > be represented as a 0 and a value of TRUE will always be represented as a 1?
> > Will an unchecked conversion from a boolean to an integer always yield the
> > same results with different compilers?
>
> Whether true or false, this is junky coding, just use
> Boolean'Pos (val) to get 0 or 1 in a for sure portable
> manner. Remember that to use an unchecked conversion for
> Boolean, you would have to use a 1-bit integer, anything
> else most definitely gives an implementation defined result.
>
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
>

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

Re: Boolean Representation

[Samuel T. Harris]

dewarr@my-dejanews.com wrote:
> 
> In article <6udkcj$87j$1@nnrp1.dejanews.com>,
>   matthew_snyder@my-dejanews.com wrote:
> > Is it safe to make the assumption that a boolean value of FALSE will always
> > be represented as a 0 and a value of TRUE will always be represented as a 1?
> > Will an unchecked conversion from a boolean to an integer always yield the
> > same results with different compilers?
> 
> Whether true or false, this is junky coding, just use
> Boolean'Pos (val) to get 0 or 1 in a for sure portable
> manner. Remember that to use an unchecked conversion for
> Boolean, you would have to use a 1-bit integer, anything
> else most definitely gives an implementation defined result.
> 

Good advice. In general I also am not concerned with the
internal representations of enumeration literals. I'm
usually concerned only with their order and the fact that
each has a unique ordinal within its type.

However, I have had occasion to be concerned with the
actual internal representation. This is where enumeration
representation clauses come in handy. Specifically, I have
had to represent a memory-mapped device with an Ada record.
One of the fields was a 16-bit flag array. A packed array
of booleans fit nicely. However, to insure the boolean
literals FALSE and TRUE have the appropriate internal
numbers, I used a derived type of boolean to which I applied
the appropriate representation clause. I know that this
might sound a bit paranoid but I tend to favor ultra-correctness
over any reliance on common compiler implementations.

-- 
Samuel T. Harris, Principal Engineer
Raytheon Training Incorporated
"If you can make it, We can fake it!"

Re: Boolean Representation

[dennison]

In article <6udkcj$87j$1@nnrp1.dejanews.com>,
  matthew_snyder@my-dejanews.com wrote:
> Is it safe to make the assumption that a boolean value of FALSE will always
> be represented as a 0 and a value of TRUE will always be represented as a 1?
> Will an unchecked conversion from a boolean to an integer always yield the
> same results with different compilers?

I believe the only guarantee you get is that the value of True is larger than
the value of False. To get the behavior you want portably, do a:

   Boolean'pos(Boolean_Variable)


--
T.E.D.

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

Re: Boolean Representation

[dennison]

In article <6ue3uh$qjo$1@nnrp1.dejanews.com>,
  matthew_snyder@my-dejanews.com wrote:
> The reason for my original question is that I'm trying to decide the best
> (most portable) way to convert an UNSIGNED_8 to a record type which provides
> access to the individual bits.	The record could either consist of
booleans,
> or it could consist of my own bit type (is there a predefined BIT type that

There are at least 12 better ways to do this! (Okay, maybe only 4 or so).

Try looking into modular types or record types of boolean with a
representation specification, or my personal favorite: arrays of booleans.

Hint: bitwise "and" and "or" are predefined on arrays of booleans.

"Let go of your C, Luke...
*Feel* the Ada."

--
T.E.D.

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

Re: Boolean Representation

[Tom Moran]

>UNSIGNED_8 to a record type which provides
>access to the individual bits.
  Would "mod 256" do the job?

Re: Boolean Representation

[Keith Thompson]

dennison@telepath.com writes:

> In article <6udkcj$87j$1@nnrp1.dejanews.com>,
[...]
> I believe the only guarantee you get is that the value of True is larger than
> the value of False.

I don't believe even that much is guaranteed.  A compiler I worked on
used, for some targets, the representation (False => 0, True => -1)
(i.e., a literal True value was represented with all bits set to 1
(2's-complement) rather than just the last bit set to 1).  This made
tests and logical operations more efficient, at the expense of some
extra code for Boolean'Pos, Boolean'Val, "<", ">", etc.

It's true that a user-defined enumeration representation clause cannot
legally specify such a representation, but there's nothing preventing
the compiler from doing so.

Of course, for a 1-bit Boolean (a member of a packed array or record),
this is equivalent to (False => 0, True => 1).

I think the original question had to do with 1-bit Booleans.  I
suppose it's conceivable that some implementation might represent
False as 1 and True as 0 in this context, but it would be perverse.

If you really care about how the bits are set, it's probably safer to
use modular types.

> To get the behavior you want portably, do a:
> 
>    Boolean'pos(Boolean_Variable)

Agreed.

-- 
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.

Re: Boolean Representation

[dewarr]

In article <360ab55c.12573963@SantaClara01.news.InterNex.Net>,
  tmoran@bix.com (Tom Moran) wrote:
> >UNSIGNED_8 to a record type which provides
> >access to the individual bits.
>   Would "mod 256" do the job?

This is an odd question: UNSIGNED_8 *is* of course mod 256.
I think you missed the point of the question, which is to
convert something of type mod 256 to individual bits.

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

Re: Boolean Representation

[Tom Moran]

>This is an odd question: UNSIGNED_8 *is* of course mod 256.
It appeared to me that the original questioner might be thinking
UNSIGNED_8 was merely a range 0 .. 255, and not thinking in terms of
its being a modular type, with OR and AND operations.  

Re: Boolean Representation

[dennison]

In article <yecogs5gidf.fsf@king.cts.com>,
  Keith Thompson <kst@king.cts.com> wrote:
> dennison@telepath.com writes:
>
> > In article <6udkcj$87j$1@nnrp1.dejanews.com>,
> [...]
> > I believe the only guarantee you get is that the value of True is larger
than
> > the value of False.
>
> I don't believe even that much is guaranteed.  A compiler I worked on
> used, for some targets, the representation (False => 0, True => -1)
> (i.e., a literal True value was represented with all bits set to 1
> (2's-complement) rather than just the last bit set to 1).  This made
> tests and logical operations more efficient, at the expense of some
> extra code for Boolean'Pos, Boolean'Val, "<", ">", etc.

I suspect their claim would be: (False => 0, True => 2**32 - 1).


--
T.E.D.

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

Re: Boolean Representation

[Keith Thompson]

dennison@telepath.com writes:
> In article <yecogs5gidf.fsf@king.cts.com>,
>   Keith Thompson <kst@king.cts.com> wrote:
[...]
> >
> > I don't believe even that much is guaranteed.  A compiler I worked on
> > used, for some targets, the representation (False => 0, True => -1)
> > (i.e., a literal True value was represented with all bits set to 1
> > (2's-complement) rather than just the last bit set to 1).  This made
> > tests and logical operations more efficient, at the expense of some
> > extra code for Boolean'Pos, Boolean'Val, "<", ">", etc.
> 
> I suspect their claim would be: (False => 0, True => 2**32 - 1).
> --
> T.E.D.

No, no such claim is necessary.  Also, this was an Ada-83 compiler
with no unsigned types (and no integer types larger than 32 bits), so
2**32-1 wasn't even a legal value.  False was represented as 0, True
was represented as -1, and the compiler generated extra code where
necessary to ensure that all the language-defined operations
(Boolean'Pos, "<", ">=", Boolean'Image, etc.) worked as specified.
The language forbids a user from specifying a non-increasing
representation for an enumeration type, but it doesn't forbid an
implementation from doing so for type Boolean.

Here's another interesting question.  Suppose some perverse
implementation used an internal representation of (False => 1, True => 0)
for type Boolean, and generated extra code to make all the predefined
operations work properly.  A packed array of 32 Booleans, for example,
would occupy 32 bits, but setting it to (others => True) would clear
all 32 bits.  I'm not suggesting that this would ever be a good idea,
but would it actually violate the RM?

-- 
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.

Re: Boolean Representation

[Robert I. Eachus]

In article <6ue3uh$qjo$1@nnrp1.dejanews.com> matthew_snyder@my-dejanews.com writes:

  > The reason for my original question is that I'm trying to decide
  > the best (most portable) way to convert an UNSIGNED_8 to a record
  > type which provides access to the individual bits. The record
  > could either consist of booleans, or it could consist of my own
  > bit type (is there a predefined BIT type that I'm overlooking?).
  > Right now my record consists of booleans and I'm performing an
  > unchecked conversion from UNSIGNED_8 to the record type. The
  > option of doing a "for RECORD'ADDRESS use SOME_ADDRESS" is not
  > available in this situation. Is any use of UNCHECKED_CONVERSION
  > considered "junky coding"?  I certainly would not want to have to
  > do a 'POS on every bit to assure portability.  What's the best way
  > to do this?

   Hmmm, do you really need the record type, or is access to the bits
enough?

 with Interfaces;
 package Bit_Manipulation is
 
   subtype Index is Integer range 1..8;

   function Get(X: Interfaces.Unsigned_8; Bit: Integer) return Boolean;
 
   procedure Set(X: in out Interfaces.Unsigned_8; Bit: in Integer);

   procedure Unset(X: in out Interfaces.Unsigned_8; Bit: in Integer);
   procedure Set(X: in out Interfaces.Unsigned_8;
                 Bit: in Integer;
                 Value: in Boolean);

   pragma Inline(Get, Set, Unset);

 end Bit_Manipulation;

 package body Bit_Manipulation is

   use Interfaces;
 
   Mask: constant array(Index) of Interfaces.Unsigned_8 := 
                                       (1,2,4,8,16,32,64,128);

   function Get(X: Interfaces.Unsigned_8; Bit: Integer) return Boolean is
   begin return (X and Mask(Bit)) /= 0; end Get;
        
   procedure Set(X: in out Interfaces.Unsigned_8; Bit: in Integer) is
   begin X := X or Mask(Bit); end Set;

   procedure Unset(X: in out Interfaces.Unsigned_8; Bit: in Integer) is
   begin X := X and not Mask(Bit); end Unset;

   procedure Set(X: in out Interfaces.Unsigned_8;
                 Bit: in Integer;
                 Value: in Boolean) is
   begin 
     if Value then Set(X, Bit); else Unset(X, Bit); end if;
   end Set;

 end Bit_Manipulation;

    I haven't checked compilers to see if the resulting code is what
you would expect for these operations, but it should come pretty close
as long as Bit is static.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Boolean Representation

[dewarr]

In article <6ue3uh$qjo$1@nnrp1.dejanews.com>,
  matthew_snyder@my-dejanews.com wrote:
> The reason for my original question is that I'm trying to decide the best
> (most portable) way to convert an UNSIGNED_8 to a record type which provides
> access to the individual bits.


ALWAYS ask what you really have in mind, don't abstract it
to something you think is similar. An unchecked conversion
of an unsigned_8 type to a packed record with 8 boolean
fields most certainly is perfectly reasonable, and has
nothing to do with converting a stand alone boolean to an
integer as implied by your original question.

Note however that it will likely be implementation dependent
(e.g. endian dependent) which order the bits come out in in
the resulting packed record.

There is no advantage in using your own type instead of
Boolean, you definitely know that when a Boolean is forced
to be represented in 1 bit, then 0 is false and 1 is true.

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

Re: Boolean Representation

[dewarr]

In article <360A8CCB.2D358953@hso.link.com>,
  "Samuel T. Harris" <sam_harris@hso.link.com> wrote:
> However, I have had occasion to be concerned with the
> actual internal representation. This is where enumeration
> representation clauses come in handy. Specifically, I have
> had to represent a memory-mapped device with an Ada record.
> One of the fields was a 16-bit flag array. A packed array
> of booleans fit nicely. However, to insure the boolean
> literals FALSE and TRUE have the appropriate internal
> numbers, I used a derived type of boolean to which I applied
> the appropriate representation clause. I know that this
> might sound a bit paranoid but I tend to favor ultra-correctness
> over any reliance on common compiler implementations.


There is a difference between relying on common compiler
implementations, and relying on the RM.

In fact the above described technique is significantly
non-portable because of 13.4(10)

   10  An implementation should support at least the
       internal codes in the range System.Min_Int..
       System.Max_Int.  An implementation need
       not support enumeration_representation_clauses
       for boolean types.

On the other hand, obviously if a boolean is stored in one
bit, False must be zero and True must be one, because
absolute ordering is required.

Your paranoia here is leading you astray into completely
unnecessary and significantly implementation dependent
coding!

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

Re: Boolean Representation

[Tucker Taft]

Keith Thompson (kst@king.cts.com) wrote:

: ...
: Here's another interesting question.  Suppose some perverse
: implementation used an internal representation of (False => 1, True => 0)
: for type Boolean, and generated extra code to make all the predefined
: operations work properly.  A packed array of 32 Booleans, for example,
: would occupy 32 bits, but setting it to (others => True) would clear
: all 32 bits.  I'm not suggesting that this would ever be a good idea,
: but would it actually violate the RM?

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.

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.

: -- 
: Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*>
: Qualcomm, San Diego, California, USA  <http://www.qualcomm.com>

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Boolean Representation

[Keith Thompson]

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.

Re: Boolean Representation

[dewarr]

In article <Ezw8Et.57H.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> 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.

No, I don't think such a rule is necessary, it is clearly the intention of
the RM that one bit boolean representations are like all other enumeration
representations in that the representations must be ordered.

Remember that when you read the RM, just because you manage to find a reading
that confirms something absurd does not mean that Ada allows absurd things.
After all, any possible reading of the Ada 83 RM that is done in this
uninformed style will tell you that virtually no subtypes are static, e.g.

   subtype x is integer range 1 .. 10;

is not a static subtype.

But this never actually bothered anyone, except the ARG who had to waste a
few minutes fixing the RM for the record.

I am not even sure that this particular issue (one bit boolean must have
rep 0/1) needs an AI. If it does, fine the ARG will issue one, but like many
many AI's this AI will have absolutely zero impact on any real user of Ada
unless they fail to understand the dynamics of the language definition.

After all, remember that there is nothing in the RM to stop an implementation
from using a loop with serial addition to implement multiplication, but even
the paranoid among Ada users do not eschew multiplication because of this.
You have to have some sense of the reasonable when using any language!

Even if you have a formal definition of a language, there can be errors in
the definition. If a typo in the formal definition ends up resulting in an
implication that "<" means ">" all this means is that there is an error in
the formal definition, not in the language being defined!

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

Re: Boolean Representation

[dewarr]

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

null pointer representation (was: Boolean Representation)

[Arthur Evans Jr]

In article <yec1zoyd2xa.fsf@king.cts.com>,
Keith Thompson <kst@king.cts.com> wrote:

> Nor can we assume that a ... null pointer is represented as all-bits-zero

Indeed not.  Some years ago I was concerned about this very issue and
asked around (probably on cla) about it.  The answers were instructive.
Most compilers did in fact use all zeros, but some other values were
used, including one compiler (from IBM, I think) that used the HEX
number DEAD BEEF.  I suppose it really stood out in HEX dumps.

Since I was interfacing to C-code in Ada-83 and code on the C side
needed zero for null pointers, I ended up writing some extra code to
ensure that value, even though the implementation I was then using
represented the null pointer as zero.

And then we never ported to another compiler, so that effort was wasted.
Well, them's the breaks.

Art Evans

Make the obvious fix to my address.

Re: null pointer representation (was: Boolean Representation)

[Keith Thompson]

evans@evans.pgh.pa.us (Arthur Evans Jr) writes:
> In article <yec1zoyd2xa.fsf@king.cts.com>,
> Keith Thompson <kst@king.cts.com> wrote:
> 
> > Nor can we assume that a ... null pointer is represented as all-bits-zero
> 
> Indeed not.  Some years ago I was concerned about this very issue and
> asked around (probably on cla) about it.  The answers were instructive.
> Most compilers did in fact use all zeros, but some other values were
> used, including one compiler (from IBM, I think) that used the HEX
> number DEAD BEEF.  I suppose it really stood out in HEX dumps.
> 
> Since I was interfacing to C-code in Ada-83 and code on the C side
> needed zero for null pointers, I ended up writing some extra code to
> ensure that value, even though the implementation I was then using
> represented the null pointer as zero.

Incidentally (and only slightly off-topic), C also does not guarantee
that a null pointer is represented as all-bits-zero.  There's enough C
code out there that assumes that it is that almost all C compilers use
the "expected" representation, but there's no such requirement.  (The
issue is further confused by the fact that the source representation
of a C null pointer is an integer literal 0.)  See the comp.lang.c FAQ
for an extensive discussion of this.

Getting back to Ada, I was a little surprised to see that the generic
package Interfaces.C.Pointers doesn't explicitly declare a constant
corresponding to a C NULL pointer, but this should be covered by the
statement that the type Pointer is C-compatible.  So Ada 95
programmers shouldn't have to worry about it as long as they use the
interfacing features provided by the language.

-- 
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.

Re: Boolean Representation

[Samuel T. Harris]

dewarr@my-dejanews.com wrote:
> 
> In article <360A8CCB.2D358953@hso.link.com>,
>   "Samuel T. Harris" <sam_harris@hso.link.com> wrote:
> > However, I have had occasion to be concerned with the
> > actual internal representation. This is where enumeration
> > representation clauses come in handy. Specifically, I have
> > had to represent a memory-mapped device with an Ada record.
> > One of the fields was a 16-bit flag array. A packed array
> > of booleans fit nicely. However, to insure the boolean
> > literals FALSE and TRUE have the appropriate internal
> > numbers, I used a derived type of boolean to which I applied
> > the appropriate representation clause. I know that this
> > might sound a bit paranoid but I tend to favor ultra-correctness
> > over any reliance on common compiler implementations.
> 
> There is a difference between relying on common compiler
> implementations, and relying on the RM.
> 
> In fact the above described technique is significantly
> non-portable because of 13.4(10)
> 
>    10  An implementation should support at least the
>        internal codes in the range System.Min_Int..
>        System.Max_Int.  An implementation need
>        not support enumeration_representation_clauses
>        for boolean types.

As to portability, any compiler which does not support
the Chapter 13 features _required_ is simply not a candidate
compiler for the project. Indeed, having the representation
clause present insures an explicit "compatibility" test
when evaluating a new compiler. If the compiler does
not support the representation clause, then I'll know
it the first time I try to compile it.

In this particular case, any compiler complaining about
the representation clause _may_ be a candidate if its
default behavior is satisfactory to the problem at hand.
The represenation clause can be commented out with
additional commentary inserted explaining the reliance
on the compiler's default representation. The extra
commentary is not necessarily for the programmers
(who should know how their compiler behaves) but for
any representatives of the hardware being interfaced
who probably do not know Ada very well but are present
at design and code reviews.

> 
> On the other hand, obviously if a boolean is stored in one
> bit, False must be zero and True must be one, because
> absolute ordering is required.
> 

I don't see anything in the RM which makes this a "must"
proposition. I have been burned many times by trusting
compilers' use "common sense" implementations, GNAT
included.

> Your paranoia here is leading you astray into completely
> unnecessary and significantly implementation dependent
> coding!
> 

I contend that relying upon default compiler representations
is "significantly implementation dependent coding", especially
when the representations matter so much. When interfacing to
hardwary, my policy is to assume nothing and to leave nothing
to chance. 

-- 
Samuel T. Harris, Principal Engineer
Raytheon Training Incorporated
"If you can make it, We can fake it!"

Re: Boolean Representation

[dewar]

In article <360E9B5E.FF081471@hso.link.com>,
  "Samuel T. Harris" <sam_harris@hso.link.com> wrote:
> As to portability, any compiler which does not support
> the Chapter 13 features _required_ is simply not a candidate
> compiler for the project. Indeed, having the representation
> clause present insures an explicit "compatibility" test
> when evaluating a new compiler. If the compiler does
> not support the representation clause, then I'll know
> it the first time I try to compile it.

That is reasonable as a general policy, but I will repeat that it is
misapplied here. Given the two choices:

1. Count on a one-bit Boolean having representation 0 for False,
and 1 for True.

2. Deriving from Boolean, and applying a rep clause.

It is clear that both from a pragmatic point of view and a formal
RM point of view, 1. is far superior, and 2. is as far as I am
concerned just wrong.

From an RM point of view, you should not rely on non-required chapter
13 features that are likely to be non-portable unless you have to. Indeed
if you have to, then Sam's approach above is of course reasonable. But
in this case, there is no need to use the rep clause, and good programming
practice is to avoid non-essential rep clauses.

For example, adding a confirming rep clause for an enumeration type is
an example of a totally unnecessary nonsense rep clause when using an
Ada 95 clause, but is at least not non-portable, since all compilers
supporting Annex C must allow this clause (even if they may well
generate inefficient code as a result).

But the RM is quite explicit in suggesting that compilers need not support
enum rep clauses for derived types of Boolean. Since such permissions are
not put in their for idle amusement, you can assume that there will indeed
be compilers that take advantage of this, e.g. to compile better code.

Yes, you can include this rep clause and use it as a filter for acceptable
compilers, but that is a bad choice, since you may be excluding a compiler
just because it does not provide a feature that you should not be using
anyway.

On the other hand, it is quite clear from the RM that the intention is
that a one-bit Boolean have representation 0,1 and it is quite impossible
to imagine that any compiler would not provide this.

Yes, I appreciate Sam may have been burned before, because you have to
definitely know quite a bit to know what you can and cannot count on,
but we are not discussing a general principle here, but rather one very
specific example.

I completely agree with Sam's general position here, I completely disagree
that the application of this general position is appropriate to this
particular case.

The pragmatic case, as opposed to the formal RM case is equally strong in
favoring approach 1, since in fact ALL Ada compilers DO of course use 0/1
as the default representation for 1-bit boolean (if you know a little about
architecture, you will know that the only reason for allowing flexibility
in boolean representation is to allow all 0 bits for False, and all 1 bits
for True, and no other non-standard choice makes sense).

On the other hand, it is definitely the case that using the rep clause may
make your program needlessly non-portable. If portability is not an issue,
that's OK, but it is remarkable how often non-portable code has to get
ported :-)

Similarly, it is quite likely that if a compiler *does* support a rep clause
for derived booleans, that it will introduce significant inefficiency in the
generated code.

Sometimes one can tolerate inefficient code if you have no choice, but here
you do have a choice.

Once again, Sam's general point of view is right here, but knowing how to
apply that position constructively and helpfully is indeed not easy. Here
at Ada Core Technologies, we find that a significant part of our support
consists of helping people use rep clauses in the most efficient way,
and to understand how their code is or is not portable.

Coding by superstition, rather than careful reasoning on a case by case
basis is almost always risky, and can definitely lead to an incorrect choice.
In particular, it is amazing how common it is, as in this case, for an
attempt at writing portable code that exactly specifies what you mean,
to be exactly counter-productive and end up making the code less portable!


Robert Dewar
Ada Core Technologies

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

Re: null pointer representation (was: Boolean Representation)

[dewarr]

In article <evans-2709981430360001@ppp23.s9.pgh.net>,
  evans@evans.pgh.pa.us (Arthur Evans Jr) wrote:
> In article <yec1zoyd2xa.fsf@king.cts.com>,
> Keith Thompson <kst@king.cts.com> wrote:
>
> > Nor can we assume that a ... null pointer is represented as all-bits-zero
>
> Indeed not.  Some years ago I was concerned about this very issue and
> asked around (probably on cla) about it.  The answers were instructive.
> Most compilers did in fact use all zeros, but some other values were
> used, including one compiler (from IBM, I think) that used the HEX
> number DEAD BEEF.  I suppose it really stood out in HEX dumps.

Art, I think this memory is wrong. At least in compilers I have seen, it is
indeed common to use DEAD BEEF for uninitialized variables, but I have not
seen it used for null pointers. If someone knows a counter example, I would
be interested.

Certainly though, you are right, Null_Address can be assumed to be all
zero bits in practice, but not Null.

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

Re: null pointer representation (was: Boolean Representation)

[Keith Thompson]

dewarr@my-dejanews.com writes:
[...] 
> Certainly though, you are right, Null_Address can be assumed to be all
> zero bits in practice, but not Null.

Why is it safe to assume that Null_Address is all zero bits?
I'd normally expect it to have the same representation as a null
pointer, though of course that's not guaranteed either.

(In any case, since Null_Address is conveniently declared in System,
there's no need to assume anything about how it's represented.)

-- 
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.

Re: null pointer representation (was: Boolean Representation)

[dewarr]

In article <yecu31su3gj.fsf@king.cts.com>,
  Keith Thompson <kst@king.cts.com> wrote:
> dewarr@my-dejanews.com writes:
> [...]
> > Certainly though, you are right, Null_Address can be assumed to be all
> > zero bits in practice, but not Null.
>
> Why is it safe to assume that Null_Address is all zero bits?
> I'd normally expect it to have the same representation as a null
> pointer, though of course that's not guaranteed either.
>
> (In any case, since Null_Address is conveniently declared in System,
> there's no need to assume anything about how it's represented.)


What is and is not safe to assume cannot be derived only from ISO standards!
For all sorts of reasons, it is safe to assume that Null_Address is all
zero bits. If you think this is wrong, cough up a counter example :-)

Still, of course it is better never to have to depend on this assumption
if you can avoid it (the same comment applies exactly equivalently to C code)

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

Re: null pointer representation (was: Boolean Representation)

[Lieven Marchand]

dewarr@my-dejanews.com writes:

> Art, I think this memory is wrong. At least in compilers I have seen, it is
> indeed common to use DEAD BEEF for uninitialized variables, but I have not
> seen it used for null pointers. If someone knows a counter example, I would
> be interested.

Question 5.17 in the comp.lang.c FAQ.

-- 
Lieven Marchand <mal@bewoner.dma.be> 
------------------------------------------------------------------------------
Few people have a talent for constructive laziness. -- Lazarus Long

Re: null pointer representation (was: Boolean Representation)

[Keith Thompson]

I posted a followup to this the other day, based on a misunderstanding
of what Robert had written (I somehow managed to read "cannot" as
"can").  I tried to cancel it; if the cancel didn't work, please
ignore my previous followup.

dewarr@my-dejanews.com writes:
> What is and is not safe to assume cannot be derived only from ISO standards!
> For all sorts of reasons, it is safe to assume that Null_Address is all
> zero bits. If you think this is wrong, cough up a counter example :-)

There are real systems out there on which the underlying operating
system uses a value other than all-bits-zero for null pointers.  As
someone else pointed out, several examples can be found in question
5.17 of the C FAQ.  On such a system, it would make perfect sense for
System.Null_Address to use the system's non-zero representation for a
null pointer.  A C compiler on such a system would very likely use
all-bits-zero to cater to poorly written existing code, but there's no
need for an Ada compiler to do so.

Even if there weren't any such machines, I don't believe that the
assumption that System.Null_Address is all zero bits would be
justified -- though admittedly my argument would be a bit weaker.

> Still, of course it is better never to have to depend on this assumption
> if you can avoid it (the same comment applies exactly equivalently to C code)

Agreed.

-- 
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.

Re: null pointer representation (was: Boolean Representation)

[Robert I. Eachus]

In article <yec1zotnlor.fsf@king.cts.com> Keith Thompson <kst@king.cts.com> writes:

  > Even if there weren't any such machines, I don't believe that the
  > assumption that System.Null_Address is all zero bits would be
  > justified -- though admittedly my argument would be a bit weaker.

   Some years back at Stratus, we used one not zero as the value for
null pointers, since it trapped if dereferenced.  When the 68020 came
along, we temporarily switched to xFFFFFFFF (I don't think that
version ever shipped.)  Then to a version of the OS where page zero
was inaccessable in user mode so that we could use zero as a null
address in user code.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...