rsync - Oct 2003 - Token.c appears to have a bug.

[A repost under a new topic since the other seems to have been lost in 
the noise]

I am basically down to one unresolved compilier diagnostic.

The HP/COMPAQ/DEC C compiler is concerned about this line in TOKEN.C

    4   22136                   temp_byte = (char) n >> 8;
       ........................................1
    %CC-I-RIGHTSHIFTOVR, (1) In this statement, the right shift count
    "8" is greater than or equal to the size of the unpromoted operand
     "(char)n".


If I am interpreting this right, the value n is an integer, and is being 
cast to be a 8 bit size.  And this results in all the higher bits being 
discarded.  So the >> should shift out all 8 remaining significant bits.

Since this is a signed value, it appears to leave what should be the 
high byte of a word either set to zero, or with possibly all bits set to 
the value of the sign bit for the character that resulted from the cast.

Is this really what is intended?  Or should there be parenthesis around 
(n >> 8) to make sure that it happens before the most significant part 
of "n" is discarded?


The actual assembly code generated is:

        LDL     R10, n           ; R10, 16(FP)
        SLL     R10, 56, R10
        SRA     R10, 63, R10
        STQ     R10, temp_byte   ; R10, 8(FP)

-John
wb8tyw@qsl.network
Personal Opinion Only

On Mon, Oct 13, 2003 at 07:29:24PM -0400, John E. Malmberg
wrote:
> Or should there be parenthesis around (n >> 8) to make sure that it
> happens before the most significant part of "n" is discarded?
Yes, there should be parens there.  Note that this bug only affects
batch mode (a fairly rare option).  Thanks for pointing this out.
I'll check in a fix in a moment.

..wayne..