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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
