tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "M. Greenblatt" <me...@mediaone.net>
Subject Re: Ajpv12InputStream.java bit op dillema
Date Fri, 02 Jun 2000 20:26:13 GMT
Ed-

Since read() is required to return an int between 0 and 255 why is it
necessary to check that this value is positive? Shouldn't we be doing
something like:


       byte bytes[] = new byte[2];

       if (read(bytes, 0, 2) != 2)
           return -1;

       return (bytes[0] << 8) | bytes[1];


And submit a bug report to the JVM developer if we're getting signed
bytes? ;-)

Also, it's not necissary to explicitly cast byte to int (though it
doesn't hurt). Finally, you might want to test if -bytes[0] is faster
than bytes[0] + 256.

-MG

(Note to respondents: I havn't migrated from JServ yet so Im not on this
list :-)


Ed Korthof wrote:
> As others said, the &0xffff this doesn't make the results any less
> correct.  However, unless the read() method is (*very*) broken, it also
> doesn't make them any more correct: read is required to return an integer
> between 0 and 255.  If it doesn't do that, we've got worse problems ...
> 
> Here's what we currently have:
> 
> ******
>         int b1 = read();
>         if( b1 ==-1)
>             return -1;
> 
>         int b2 = read();
>         if ( b2==-1)
>             return -1;
> 
>         return ((int)((b1 << 8) | b2)) & 0xffff;
> ******
> 
> The following is slightly faster (not enough to matter -- 10s of ms for
> 10,000 iterations); but it doesn't seem any clearer to me:
> 
> *****
>        byte bytes[] = new byte[2];
> 
>        if (read(bytes, 0, 2) != 2)
>            return -1;
> 
>        int val = (bytes[0] < 0 ? (int)bytes[0] + 256 : (int)bytes[0])<<8;
>        val +=    (bytes[1] < 0 ? (int)bytes[1] + 256 : (int)bytes[1]);
> 
>        return val;
> *****
> 
> I wouldn't mind changing the code to make it clearer, but the difference
> in efficiency isn't large enough to justify a change which make make the
> code even less clear.
> 
> Anyway, this certainly isn't a big deal, I was just curious about it. ;-)
> 
> thanks --
> 
> Ed

Mime
View raw message