1. RE: BUG in or_bits
Can it be a bug if it's documented?
>From the reference manual: "Results are treated as signed numbers. They
will be negative when the highest-order bit is 1."
constant mask = #FFFF0000
constant result = or_bits( mask, 0 )
-- it all depends on how you'd like to represent it...
printf(1,"or_bits(#FFFF0000,0) = %d = 0x%x\n", {result,result} )
-- Brian
Bernie Ryan wrote:
>
> There is a bug in or_bits() results, here is the simplest example
> I can use to demonstrate this. Try running this code.
> OR bits should return unsigned results.
>
> -- SOMETHING IS WRONG WITH PRINTING THE OR_BITS() RESULTS
> printf(1,"%d\n",or_bits(#FFFF0000,0))
> ? or_bits(#FFFF0000,0)
>
> -- THIS IS WHAT SHOULD BE PRINTED
> printf(1,"%d\n",#FFFF0000)
> ? #FFFF0000
>
> Bernie
>
2. RE: BUG in or_bits
Brian Broker wrote:
> Can it be a bug if it's documented?
Brian:
Thanks Brian.
But there is no such restriction placed on it in "C"
if it is suppose to be a logical OR.
What about errors that it could cause in WINDOWS
and other "C" code when oring things together.
Bernie
3. RE: BUG in or_bits
> -----Original Message-----
> From: Derek Parnell [mailto:ddparnell at bigpond.com]
> Unfortunately its not a bug (in the strict sense 'cos its
> documented), but
> it is a non-optimal design decision on RDS's part. I agree it
> should treat
> the atom as 32 bits rather than a signed integer.
>
> 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.
>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. 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). 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]
although Derek's method seems to be about 5% faster (and, I think, more
elegant). Subtituting the calculation of int_to_bits(0,32) with a constant
gives me another 25% improvement.
Matt Lewis
4. RE: BUG in or_bits
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
---------------------
