On , Robin Sheppard (1:153/9{at}fidonet) wrote: 

 RS> The only problem is that these will fail if you try to use them with a
 RS> long integer of any sort. The solution is real simple, as this excerpt
 RS> from BITOPS.H in SNIPPETS shows...

 > Yeah, I was aware that using longs would be a problem. I only intended 
 > these for use on 8- and 16-bit (ints are 16-bit on my compiler) values.

Robin...

  On the compilers I use most, int's are also 16 bit - but long's are 32 bits.

 > There are _lrotl() and _lrotr() routines in my compiler's library, so I 
 > assumed it was a limitation of the architecture, or at least real mode, 
 > which made regular shifts impossible with longs.

  It sounds like you might be using Micro-C. Intel architecture in real
mode handles 32-bit longs just fine. I'm assuming you're using an Intel
architecture chip since you referred to real mode.

 > Given your explanation, and some more reading I've done (I'm trying to 
 > teach myself assembler), I think it's the difference between 'shift' and 
 > 'rotate' that is at issue.  When shifting bits to the left, the low bits 
 > will be zero, and the high bits will be lost, but when rotating left, the
 > high bits will replace the 'empty' low bits.

  Actually, in C, all of the standard >> and << operators are
logical shifts. Arithmetic shifts and rotates aren't defined operations,
even though they may be supported in the underlying machine language.

 RS> ..which assures that BitTst() returns either a 1 or 0 as do other logical
 RS> tests in C without resorting to the ternary operator.

 > What's wrong with using the conditional operator here?  I always thought 
 > it was a handy way of shortening an otherwise more lengthy operation.

  It is, but it may not be the most efficient on a particular architecture.
In fact, in this case, I don't believe it makes any difference. 


--- QM v1.00