[GRASS-dev] Re: i.modis.qc

[Paul Kelly]

Hi Yann,
Thought I would comment too so you know it is not just Glynn who sees 
there is a problem here.

On Mon, 27 Oct 2008, Yann Chemin wrote:

> Hello Glynn,
>
> since I rewrote the code, and tested it, I know quite much what I do
> with the bitshifts, the image input, and the classification resulting
> from bitshifts.
>
> I have not seen so far any need to >>= instead of >>, in any of the
> related code I read.

Well, it is not in doubt that the statement with the bit shift does not 
do anything and has no effect. So if you feel it works OK the way it is 
then that statement can be safely removed with no effect.

> My worry in this email below was that a non-Unix platform compiler
> (which I don't have) would cough on it for some unknown reason to me.

Whether or not there is a warning is a moot point (apart from the fact 
that because we're only finding this bug because of a warning, it suggests 
there could be other undiscovered bugs in the code that aren't generating 
warnings). Anyway as Glynn said, the point is that a statement like 
qctemp >> 2;
does not do anything. qctemp is not modified as a result; the bit-shifted 
value theoretically exists in the ether for an instant, but it is not 
assigned to anything so it is lost again instantly. That statement can be 
removed from the program and the output will be exactly the same.

> As I can imagine, the compiler would find strange there is no variable
> data allocation in a line of code, but I would expect it to understand
> the unique feature of bitshift too.

What do you mean? Bitshift doesn't have a unique feature; it works just 
like any other operator like + or - or | or &.

Paul