This is the mail archive of the guile@cygnus.com mailing list for the guile project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gsubr.c: C << operator question.

Gordon Matzigkeit wrote:
> 
> Hi!
> 
> >>>>> "Gord" == Gordon Matzigkeit <gord@trick.fig.org> writes:
> >>>>> Karl M Hegbloom writes:
> 
>  KMH> ... Why does it first << 8 and then right away do >> 8,
>  KMH> recompute and compare like that?  How could the value change?
> 
>  Gord> (x << 8) >> 8 == x with the top 8 bits cleared
> 
>  KMH>  Ok, so wouldn't it be faster to use (x & 0xff)?
> 
> Only if X is a 16-bit variable.  For a long on a 32-bit machine, you'd
> want (x & 0xffffff), so ideally you'd make the compiler do all that
> dirty work for you: (x & (((unsigned long) -1) >> 8)).
> 
> But there's one more complication: sign extension.  When you
> right-shift a signed quantity that is negative, the new high bits get
> set rather than cleared.

Um, is this necessarily true?  I searched all the C/C++ reference
books I can find on my bookshelf, and although the newest one I have
is from 1991 (Stroustrop, "The C++ Programming Language", 2.ed),
they all say:

        "The value of E1 >> E2 is E1 right-shifted E2 bits.  The
        right shift is guaranteed to be logical (0-fill) if E1
        has an unsigned type or if it has a non-negative value;
        otherwise the result is implementation dependent."

I ran t.c through all the compilers I could find (HP-UX, SOLARIS,
Digital UNIX, AIX, Visual C++); they all generated arithmetic 
right shifts for the signed long value.  Did the standard get
amended somewhere along the line?

Greetings, Jim

-- 
===================================================================
James S. Rauser                                rausejme@kou3.ina.de
Ina Werk Schaeffler KG/Abt. KOU3                  +49 9132 82 32 43
Industriestrasse 1-3                  91074 Herzogenaurach, Germany