LLQ: -1 a valid boolean?

LLQ: -1 a valid boolean?

[Ted Dennison]

At work our Ada program has to interface to two other languages; C and
Fortran. We get addresses from them, which are converted into pointers
to known data types, for instance Boolean.

The C code is using 1 for True, so we had no problem there. But the
Fortran code uses -1 for boolean. Now since Boolean'Size = 1, I figured
that would be fine too. It shouldn't care what the other bits are. And
it is perfectly fine, if you just use the result from the address.  But
if I try to assign that value out into another boolean variable, I get a
Constratint_Error! eg:


     package Boolean_Ptr_Conversions is new
     System.Address_To_Access_Conversions (Boolean);
     Fortran_True : Integer := -1;
     Ada_Boolean : Boolean;
     ...
     Ada.Text_IO.Put_Line ("Value is " &
     Boolean'image(Boolean_Ptr_Conversions.To_Pointer(Fortran_Integer'Address).all));

     -- Above runs fine, and prints out "Value is TRUE"

     Ada_Boolean :=
     Boolean_Ptr_Conversions.To_Pointer(Fortran_Integer'Address).all;

     -- Above raises Constraint_Error w/ certian compiler, not w/
     Gnat.


What I'm wondering is if this is legal behavior for the compiler, or if
I should submit a bug report?

You'd think that a value that is legal in situ ought to be legal to
assign as well. Then again, if Ada_Boolean'Size = 8 or 32 or something,
then I can see where one might argue that a value of -1 (all bits set)
is out of range of the possible Boolean values, and thus should raise
Constraint_Error.

So what's right?

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: LLQ: -1 a valid boolean?

[Jeff Carter]

Ted Dennison wrote:
>      Fortran_True : Integer := -1;

Shouldn't you be using Interfaces.Fortran.Logical? Which is guaranteed
to be FORTRAN compatible?

-- 
Jeff Carter
"Son of a silly person."
Monty Python & the Holy Grail

Re: LLQ: -1 a valid boolean?

[Ted Dennison]

Jeff Carter wrote:

> Ted Dennison wrote:
> >      Fortran_True : Integer := -1;
>
> Shouldn't you be using Interfaces.Fortran.Logical? Which is guaranteed
> to be FORTRAN compatible?

No, because the boolean could have come from C or Fortran or Ada.
Interfaces.Fortran.Logical is not guaranteed to be C compatable.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: LLQ: -1 a valid boolean?

[Robert Dewar]

In article <39253CD0.C8DC893D@telepath.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> You'd think that a value that is legal in situ ought to be
> legal to assign as well. Then again, if Ada_Boolean'Size = 8
> or 32 or something, then I can see where one might argue that
> a value of -1 (all bits set) is out of range of the possible
> Boolean values, and thus should raise
> Constraint_Error.
>
> So what's right?

Not only is the compiler's behavior conforming, it is actually
what one would expect, given that you most certainly expect
that boolean objects have a size of 8 (the choice of a size
of 1 for boolean objects is typically impractical on most
architectures due to the task indepedence requirement).

Your code is just wrong here, and you are going to have to
deal with these booleans in a completely different manner.

If your compiler implements Interfaces.Fortran, then everything
should be fine, since the type Logical should work properly.

However, you may well find that even if your compiler says it
supports Interfaces.Fortran, it may get Logical wrong. That
was certainly the case with earlier versions of GNAT (a bad
gap in the ACVC tests is that there are no tests for proper
implementation of Logical, and the requirements are subtle).

The trouble is that Logical is derived from Boolean, but is
required to have completely different semantics from normal
Booleans, namely zero/nonzero semantics like C.

What we did in GNAT was implement a completely general facility
that allows derived booleans to be given a convention of C or
Fortran, and then they implement full zero/nonzero semantics.
This was definitely a non-trivial implementation effort, since
all sorts of special cases arise (we now for the first time have
a many-to-one mapping for the pos function for example).

So in GNAT, you can solve this problem by simply using pragma
Convention (Fortran, ...) but I don't think any other compilers
implement this feature in general terms. Whether any other
compilers properly implement Logical I don't know. Here's the
test we use for this purpose in our regression suite at Ada
Core Technologies:

with Interfaces.Fortran; use Interfaces.Fortran;
with Unchecked_Conversion;
with Text_IO; use Text_IO;

procedure q is
   B : Boolean;
   L : Logical;
   I : Short_Short_Integer;

   Passed : Boolean := True;

   function To_L is new Unchecked_Conversion (Integer, Logical);
   function From_B is new Unchecked_Conversion (Boolean,
Short_Short_Integer);

   AL : array (1 .. 1) of Logical;

begin
   goto Next;
   <<Next>>
   L := To_L (2);
   AL (1) := L;

   if Logical'Pos (L) /= 1 then
      Put_Line ("wrong pos value for L");
      Passed := False;
   end if;

   if L then
      null;
   else
      Put_Line ("true value of L does not look true");
      Passed := False;
   end if;

   if not L'Valid then
      Put_Line ("L looks invalid");
      Passed := False;
   end if;

   if  (L > True or True < L) then
      Put_Line ("complex condition handled incorrectly");
   end if;

   if  (L > True or else True < L) then
      Put_Line ("complex short circuit condition handled
incorrectly");
   end if;

   if Logical'Pos (AL (1)) /= 1 then
      Put_Line ("wrong pos value for AL (1)");
      Passed := False;
   end if;

   if AL (1) then
      null;
   else
      Put_Line ("true value of AL (1) does not look true");
      Passed := False;
   end if;

   if not AL (1)'Valid then
      Put_Line ("AL (1) looks invalid");
      Passed := False;
   end if;

   if  (AL (1) > True or True < AL (1)) then
      Put_Line ("complex condition handled incorrectly");
   end if;

   if  (AL (1) > True or else True < AL (1)) then
      Put_Line ("complex short circuit condition handled
incorrectly");
   end if;

   B := Boolean (L);
   I := From_B (B);

   if I /= 1 then
      Put_Line ("wrong boolean value from conversion");
      Passed := False;
   end if;

   if Passed then
      Put_Line ("passed");
   end if;
end q;

(well there are some other tests as well, but they are based
on customer proprietary code, so they cannot be posted. It was
a customer doing interfacing to Fortran who first brought this
to our attention).

Robert Dewar
Ada Core Technologies

P.S. This was implemented in GNAT version 3.12


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: LLQ: -1 a valid boolean?

[Ted Dennison]

In article <8g8o3b$9l0$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <39253CD0.C8DC893D@telepath.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
> > You'd think that a value that is legal in situ ought to be
> > legal to assign as well. Then again, if Ada_Boolean'Size = 8
> > or 32 or something, then I can see where one might argue that
> > a value of -1 (all bits set) is out of range of the possible
> > Boolean values, and thus should raise
> > Constraint_Error.
> >
> > So what's right?
>
> Not only is the compiler's behavior conforming, it is actually
> what one would expect, given that you most certainly expect
> that boolean objects have a size of 8 (the choice of a size
> of 1 for boolean objects is typically impractical on most
> architectures due to the task indepedence requirement).
>
> Your code is just wrong here, and you are going to have to
> deal with these booleans in a completely different manner.

That's what I was afraid of.

> If your compiler implements Interfaces.Fortran, then everything
> should be fine, since the type Logical should work properly.

Except that sometimes the value comes from a Fortran program, and
sometimes it comes from a C program.

I just ended up doing the following, which looks damn silly (so I had
to comment it copiously), but works:

   if To_Bool_Ptr(Addr).all then
      return True;
   else
      return False;
   end if;

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: LLQ: -1 a valid boolean?

[Robert Dewar]

In article <8ge39b$g45$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> > If your compiler implements Interfaces.Fortran, then
everything
> > should be fine, since the type Logical should work properly.
>
> Except that sometimes the value comes from a Fortran program,
and
> sometimes it comes from a C program.

That;s fine Fortran.Logical will work in either case

> I just ended up doing the following, which looks damn silly
> (so I had to comment it copiously), but works:

>    if To_Bool_Ptr(Addr).all then
>       return True;
>    else
>       return False;
>    end if;

It's not only silly, it is incorrect. There is absolutely NO
reason to think this should work correctly, since you are
testing an out of range and hence abnormal value, and the
result of this test is undefined.

You should use unchecked conversion to convert it to an unsigned
integer of the approipriate size, and check that integer for
a non-zero value.

Writing erroneous code like this and being satisied that it
happens to work on the particular compiler you are using is
not a good approach to writing reliable code!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: LLQ: -1 a valid boolean?

[Ted Dennison]

In article <8gen6a$v72$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <8ge39b$g45$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
> > I just ended up doing the following, which looks damn silly
> > (so I had to comment it copiously), but works:
>
> >    if To_Bool_Ptr(Addr).all then
>
> It's not only silly, it is incorrect. There is absolutely NO
> reason to think this should work correctly, since you are
> testing an out of range and hence abnormal value, and the
> result of this test is undefined.

Ahh, that's a different kettle of fish. I thought the verdict was that
this was a valid test, since Boolean'Size is 1, but that assigning it
was wrong becuse Boolean_Object'Size > 1.

So you are saying both are wrong? That's exactly what I was asking
about.

> Writing erroneous code like this and being satisied that it
> happens to work on the particular compiler you are using is
> not a good approach to writing reliable code!

Quite so. The last thing I want is to be called out to timbucktoo for a
week to figure out why part of the simulator fails 6 weeks after they
take a minor compiler upgrade. Worse yet would be to inflict that fate
on some other innocent engineer.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: LLQ: -1 a valid boolean?

[Robert Dewar]

In article <8geplk$10e$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> Ahh, that's a different kettle of fish. I thought the verdict
> was that this was a valid test, since Boolean'Size is 1, but
> that assigning it was wrong becuse Boolean_Object'Size > 1.

Boolean'Size is completely irrelevant

What is relevant is that you have an object of type Boolean
that has an abnormal value (other than 0 or 1), and any
reference to this abnormal value is erroneous.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: LLQ: -1 a valid boolean?

[Ted Dennison]

Robert Dewar wrote:

> In article <8geplk$10e$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
>
> > Ahh, that's a different kettle of fish. I thought the verdict
> > was that this was a valid test, since Boolean'Size is 1, but
> > that assigning it was wrong becuse Boolean_Object'Size > 1.
>
> Boolean'Size is completely irrelevant
>
> What is relevant is that you have an object of type Boolean
> that has an abnormal value (other than 0 or 1), and any
> reference to this abnormal value is erroneous.

Hmm. So you are saying "size doesn't matter"?  :-)

Well, at some point, I'd think it would have to. Suppose there's an
exterranious bit set 33 bits away from boolean's significant bit?

Or are you saying that Boolean'Size doesn't matter, but
Boolean_Object'Size does?

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: LLQ: -1 a valid boolean?

[Robert Dewar]

In article <392B1C0F.1D8DEB3A@telepath.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> Or are you saying that Boolean'Size doesn't matter, but
> Boolean_Object'Size does?


This concentration on size is not at all helpful, it is just
misleading.

You have a boolean object that has a value that is abnormal.
Referencing such a object is erroneous! That's that!

True, if the object had a size of 1, it could not have an
abnormal value, but you know that a stand alone object does
not have a size of 1!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: LLQ: -1 a valid boolean?

[David C. Hoos, Sr.]

return To_Bool_Ptr(Addr).all;

might look a little less "silly" than

   if To_Bool_Ptr(Addr).all then
      return True;
   else
      return False;
   end if;

Ted Dennison <dennison@telepath.com> wrote in message
news:8ge39b$g45$1@nnrp1.deja.com...
> In article <8g8o3b$9l0$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> > In article <39253CD0.C8DC893D@telepath.com>,
> >   Ted Dennison <dennison@telepath.com> wrote:
> > > You'd think that a value that is legal in situ ought to be
> > > legal to assign as well. Then again, if Ada_Boolean'Size = 8
> > > or 32 or something, then I can see where one might argue that
> > > a value of -1 (all bits set) is out of range of the possible
> > > Boolean values, and thus should raise
> > > Constraint_Error.
> > >
> > > So what's right?
> >
> > Not only is the compiler's behavior conforming, it is actually
> > what one would expect, given that you most certainly expect
> > that boolean objects have a size of 8 (the choice of a size
> > of 1 for boolean objects is typically impractical on most
> > architectures due to the task indepedence requirement).
> >
> > Your code is just wrong here, and you are going to have to
> > deal with these booleans in a completely different manner.
>
> That's what I was afraid of.
>
> > If your compiler implements Interfaces.Fortran, then everything
> > should be fine, since the type Logical should work properly.
>
> Except that sometimes the value comes from a Fortran program, and
> sometimes it comes from a C program.
>
> I just ended up doing the following, which looks damn silly (so I had
> to comment it copiously), but works:
>
>    if To_Bool_Ptr(Addr).all then
>       return True;
>    else
>       return False;
>    end if;
>
> --
> T.E.D.
>
> http://www.telepath.com/~dennison/Ted/TED.html
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: LLQ: -1 a valid boolean?

[Robert Dewar]

In article <8gebvj$20i$1@hobbes2.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> return To_Bool_Ptr(Addr).all;
>
> might look a little less "silly" than
>
>    if To_Bool_Ptr(Addr).all then
>       return True;
>    else
>       return False;
>    end if;

But the return statement *obviously* would not work in this
context, since we know that the value is abnormal! We can
see why the if statement might in practice work, but for
sure the return statement will not work (be sure to read
the earlier messages in this thread, don't just examine
the above code at face value!)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: LLQ: -1 a valid boolean?

[David C. Hoos, Sr.]

Robert Dewar <robert_dewar@my-deja.com> wrote in message
news:8gfe1m$enu$1@nnrp1.deja.com...
> In article <8gebvj$20i$1@hobbes2.crc.com>,
>   "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> > return To_Bool_Ptr(Addr).all;
> >
> > might look a little less "silly" than
> >
> >    if To_Bool_Ptr(Addr).all then
> >       return True;
> >    else
> >       return False;
> >    end if;
>
> But the return statement *obviously* would not work in this
> context, since we know that the value is abnormal! We can
> see why the if statement might in practice work, but for
> sure the return statement will not work (be sure to read
> the earlier messages in this thread, don't just examine
> the above code at face value!)
>
I certainly stand corrected if there was some earlier
definition of To_Bool_Ptr that would have enabled me to see
that "we know that the value is abnormal!"  I had searched
for To_Bool_Ptr in my newsreader's comp.lang.ada messages,
and found no prior reference, so I (foolishly) assumed that
it was a function returning a not abnormal value.

Re: LLQ: -1 a valid boolean?

[Ted Dennison]

In article <0wOW4.27734$T41.665890@newsread1.prod.itd.earthlink.net>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
>
> Robert Dewar <robert_dewar@my-deja.com> wrote in message
> news:8gfe1m$enu$1@nnrp1.deja.com...
> > In article <8gebvj$20i$1@hobbes2.crc.com>,
> >   "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> > > return To_Bool_Ptr(Addr).all;
> > >
> > > might look a little less "silly" than
> > >
> > >    if To_Bool_Ptr(Addr).all then
> > >       return True;
> > >    else
> > >       return False;
> > >    end if;
> >
> > But the return statement *obviously* would not work in this
> > context, since we know that the value is abnormal! We can
> > see why the if statement might in practice work, but for
> > sure the return statement will not work (be sure to read
> > the earlier messages in this thread, don't just examine
> > the above code at face value!)
> >
> I certainly stand corrected if there was some earlier
> definition of To_Bool_Ptr that would have enabled me to see
> that "we know that the value is abnormal!"  I had searched
> for To_Bool_Ptr in my newsreader's comp.lang.ada messages,
> and found no prior reference, so I (foolishly) assumed that
> it was a function returning a not abnormal value.
>
>
Then I suppose the fault is at least partially mine, for taking the easy
way out and not including all the proper context information. It should
have been more like:


     package Boolean_Ptr_Conversions is new
     System.Address_To_Access_Conversions (Boolean);
     Fortran_True : Integer := -1;
     Ada_Boolean : Boolean;
     ...
     if Boolean_Ptr_Conversions.To_Pointer(Fortran_True) then
        return True;
     else
        return False;
     end if;


I figured that since Boolean'Size=1, then the check ought to work, even
if assiging the value causes Constraint_Error. Oddly enough, even though
my logic was faulty, in this instance I was right. But if the comparison
itself is erronious, then this is not the way to do it.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: LLQ: -1 a valid boolean?

[Robert Dewar]

In article <8ggq7i$dad$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> I figured that since Boolean'Size=1, then the check ought to
> work

I really can't imagine what you are thinking here. Boolean'Size
being 1 affects precisely two things, the behavior of unchecked
conversion, and the effect of component packing, nothing else
at all. If it does something else, then you have a
misunderstanding of some kind.

> even
> if assiging the value causes Constraint_Error.

Assigning the value is of course erroneous, so it might cause
CE indeed.

> in this instance I was right.

Not at all odd, because it simply means that the check
checked for zero/non-zero which is certainly legal (and
somewhat expected since it is more efficient than explicitly
checking for equality with 1).

> But if the comparison
> itself is erronious, then this is not the way to do it.

Indeed, since this behavior is not guaranteed.

Does the compiler you are using support Fortran.Logical? It
should if it claims to support Annex G, since Annex G expects
interface to Fortran to be implemented if fortran is available.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: LLQ: -1 a valid boolean?

[Robert Dewar]

In article
<0wOW4.27734$T41.665890@newsread1.prod.itd.earthlink.net>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> I certainly stand corrected if there was some earlier
> definition of To_Bool_Ptr that would have enabled me to see
> that "we know that the value is abnormal!"  I had searched
> for To_Bool_Ptr in my newsreader's comp.lang.ada messages,
> and found no prior reference, so I (foolishly) assumed that
> it was a function returning a not abnormal value.


I would guess you are not using a thread following newsreader
:-)

This whole thread is about handling abnormal boolean values!
See the first message in the thread to see the setting of the
stage!


Sent via Deja.com http://www.deja.com/
Before you buy.