1. RE: BUG in or_bits
- Posted by Brian Broker <bkb at cnw.com> Jun 04, 2001
- 389 views
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
- Posted by Bernie Ryan <xotron at localnet.com> Jun 04, 2001
- 391 views
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
- Posted by Matthew Lewis <matthewwalkerlewis at YAHOO.COM> Jun 04, 2001
- 389 views
> -----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
- Posted by Derek Parnell <ddparnell at bigpond.com> Jun 04, 2001
- 394 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 ---------------------