OpenEuphoria

RE: BUG in or_bits

• Posted by Derek Parnell <ddparnell at bigpond.com> Jun 04, 2001
• 393 views

Hi Matt,

> -----Original Message-----
> From: Matthew Lewis [mailto:matthewwalkerlewis at YAHOO.COM]
> Sent: Tuesday, 5 June 2001 7:44 AM
> To: EUforum
> Subject: RE: BUG in or_bits
>
> Derek wrote:
> > I would rather that
> >  #FFFF0000 = or_bits(#FFFF0000,0)
> > was true so that I could SAFELY use this when using flags in
> > Windows code
> > etc...
>
> Why can't you use this safely?  As long as you use or_bits
> (rather than my
> lazy shortcut of simply adding flags together) you're safe.

Its not that the bits are wrong, because they are not. The inconsistency is
that in C code I can do this sort of thing ...

#define Dying (0x80000000)

    int Action(unsigned int pFlag, Entity *e)
    {
      unsigned int r;
      r = e->Status | pFlag;

      if (r == Dying)
      {
        ...
      };

      return r;
   }

the (seemingly) equivilent Euphoria code ...

constant Dying = #80000000

    function Action(atom pFlag, sequence e)
      atom r;

      r = or_bits(e[Status], pFlag)
      if r = Dying then
        ...
      end if
      return r
   end function

However the or_bits returns a signed integer rather than a 32-bit atom, thus
you cannot do the simple equality test anymore.

Its unsafe in the sense that one cannot do a simple equality test if the
high-order bit is set in either atom of the or_bits() parameters. However,
this would be a rare thing to do. To most people it is not intuitive to be
wary of. Is there any good reason to return a signed integer rather than a
32-bit atom?

> >From Refman (define_c_proc):
>
> "In C (on WIN32 and Linux), parameter types which use 4 bytes
> or less are
> all passed the same way, so it is not necessary to be exact."
>
> I've confirmed this in practice, as well, passing a negative
> integer or a
> 32-bit value.  You also confirm this with printf (that the bits are
> correct).  So it's not really that the bits are wrong, as the
> result is
> returned as an [Euphoria] integer.

Agreed. The bits are right, its the interpretation that Euphoria does thats
a problem.

>Maybe what we need is a
> way to convert
> between signed/unsigned values.  I wrote a little routine in
> variant.ew
> (part of EuCOM) to convert between signed 1 and 2-bit
> integers, since there
> are no peeks/u/2s/2u routines.
>
> However, I suspect Rob would question how often this would be
> used (the conversion, that is).

Conversion should not be required because it is a BIT operation and not a
NUMERIC operation. If Euphoria has to represent bit strings as numbers then
it should do it in a consistent manner. But you're right, its probably too
rare for RDS to concern themselves with, besides if you happen to detect the
"feature" (i.e. you program fails) there are work arounds to correct it 

>  For bitwise operations, there's Derek's method:
>
> > -- A real 32-bit OR operation
> > s =  bits_to_int((int_to_bits(#FFFF0000, 32) or int_to_bits(0,32)) )
> > printf(1, "%d %x\n", {s,s})
>
> or something like:
> x = value( sprintf("#%x",or_bits(#FFFF0000,0)))
> x = x[2]
>

Or maybe a "safe" or_bits() like ...

function Safe_or_bits(atom a, atom b)
   return bits_to_int((int_to_bits(a, 32) or int_to_bits(b,32)) )
end function
-----------
cheers,
Derek Parnell
Senior Design Engineer
Global Technology Australasia Ltd
dparnell at glotec.com.au

---------------------