Token.c appears to have a bug.

John E. Malmberg wb8tyw at qsl.net
Tue Oct 14 09:29:24 EST 2003


[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 at qsl.network
Personal Opinion Only





More information about the rsync mailing list