[sane-devel] New magicolor backend for inclusion in git
Richard Ryniker
ryniker at alum.mit.edu
Sat Jan 22 19:40:23 UTC 2011
Reinhold Kainhofer <reinhold at kainhofer.com> wrote:
>If I use "unsigned char*", then I get no warning. However, I fail to see why
>using an additional variable makes a difference...
>
>This does not work (&b[0] is a pointer to an unsigned char, right?):
> unsigned char b[4];
> htole32a(&b[0], value);
>
>while this does:
> unsigned char b[4];
> unsigned char *bp=&b[0];
> htole32a(bp, value);
The first argument to htole32a must be an lvalue. It is used in the
left-hand side of an assignment by htole32a; this is the exact meaning of
lvalue.
b[0] is an lvalue. It is certainly well-defined to write something like:
b[0] = 2;
&b[0] looks like it should be the address of the first element of b, and
indeed it is, but it is not an lvalue: it does not denote a target (such
as a variable) to which some value may be assigned. It is not a pointer
type, which can be dereferenced by the * operator. What is needed for the
first argument of htole32a is a pointer P that can be used in a statement
like:
*P = 2;
The statement:
unsigned char * bp=&b[0];
is well-defined: the variable bp is assigned a value which is the address
of the unsigned char b[0]. bp is an actual variable, therefore it is an
lvalue and an acceptable first argument to ntole32a.
A statement such as:
*&b[0] = 2;
is invalid according to the C language grammar (even if you, a human, can
say you know what it should mean). That is why the compiler complains
when it parses:
htole32a(&b[0], value);
but the compiler is happy with the correct:
htole32a(bp, value);
because that expands into:
*bp = value;
More information about the sane-devel
mailing list