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

Glynn Clements glynn at gclements.plus.com
Sun Oct 26 11:00:04 EDT 2008


Yann Chemin wrote:

> maybe it is wiser indeed to change to ">>=" for platform/compiler
> stability as it forces the variable to be updated.
> Somehow it is not necessary on my system (Debian/Sid).

If you want to modify the variable, you need to use >>=. >> just
returns the shifted value, which is pointless in this particular case.

A statement like:

	x >> 1;

makes no more sense than:

	x + 1;
or:
	x * 2;

There's no point evaluating an expression unless you're going to do
something with the result, e.g. assign it to a variable, or pass it to
a function which will make use of it.

If you aren't getting warnings, that's probably because your CFLAGS
doesn't include -Wall or similar. The expression is perfectly valid C,
so you won't get a warning by default. -Wall enables various optional
warnings, including warnings for code which is valid but which might
not do what you expect (e.g. "if (x = 0) ..." is valid, but it's more
likely to be a typo for "if (x == 0) ...").

However, there is still the question of which variable should be
updated. E.g. in qc250b():

    qctemp >> 2;		/*bits [2-3] become [0-1] */
    qctemp = pixel & 0x03;

Changing this to >>=:

    qctemp >>= 2;		/*bits [2-3] become [0-1] */
    qctemp = pixel & 0x03;

is equally pointless, as you would be modifying qctemp then
immediately discarding the modified value. Both of the above versions
are equivalent to just:

    qctemp = pixel & 0x03;

Which leads me to suspect that it's "pixel" which should have been
shifted, not qctemp.

If you don't understand what this code is supposed to do, please
remove it. I don't understand what it's supposed to do either, so I
can only notice things which are obvious mistakes, not anything which
*could* plausibly be correct but actually isn't.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list