invalid lvalue

[Paul Edwards]

The following code:

int main(void)
{
char *x;

(void **)x += 1;
return (0);
}

gives "invalid lvalue in assignment" when compiled with
the 64-bit Fedora Core 4 build of gcc 4.1.1.

But it works fine with other versions of gcc, and other compilers,
and the operation I want done looks entirely logical to me.

Is this code C90-compliant or not?

Thanks. Paul.

 

[pete]

The following code:

int main(void)
{
char *x;

(void **)x += 1;
return (0);
}

gives "invalid lvalue in assignment" when compiled with
the 64-bit Fedora Core 4 build of gcc 4.1.1.

But it works fine with other versions of gcc, and other compilers,
and the operation I want done looks entirely logical to me.

Is this code C90-compliant or not?

No.
The result of a type conversion, can't be an lvalue.

 

[Joe Wright]

The following code:

int main(void)
{
char *x;

(void **)x += 1;
return (0);
}

gives "invalid lvalue in assignment" when compiled with
the 64-bit Fedora Core 4 build of gcc 4.1.1.

But it works fine with other versions of gcc, and other compilers,
and the operation I want done looks entirely logical to me.

Is this code C90-compliant or not?

Thanks. Paul.

I can't imagine that code works anywhere. First x is defined a pointer
but doesn't point anywhere, its value is indeterminate. The result of a
cast can never be an lvalue.

 

[CBFalconer]

The following code:

int main(void) {
char *x;

(void **)x += 1;
return (0);
}

gives "invalid lvalue in assignment" when compiled with
the 64-bit Fedora Core 4 build of gcc 4.1.1.

But it works fine with other versions of gcc, and other compilers,
and the operation I want done looks entirely logical to me.

Is this code C90-compliant or not?

Not. The LHO is not a left-value. Looks like they improved gcc.

 

[Keith Thompson]

I can't imagine that code works anywhere. First x is defined a pointer
but doesn't point anywhere, its value is indeterminate.

Right, and the result of operating on an indeterminate value needn't
be visibly bad.

The result of
a cast can never be an lvalue.

Unless the compiler supports it as an extension, as explicitly allowed
by C99 4p6. But a conforming compiler must still issue a diagnostic
<OT>as gcc will do when invoked with the correct options</OT>.

 

[Paul Edwards]

I can't imagine that code works anywhere. First x is defined a pointer
but doesn't point anywhere, its value is indeterminate.

Well, the real code it is in has a defined value. This is just for
illustration.

The result of a cast can never be an lvalue.

Ok, thanks all. I'll change the code. The code in question is
actually in the obstack_ptr_grow() macro on line 426 of
include/obstack.h in gcc 3.2.3.

BFN. Paul.

 

[Army1987]

The following code:

int main(void)
{
char *x;

(void **)x += 1;
return (0);
}

gives "invalid lvalue in assignment" when compiled with
the 64-bit Fedora Core 4 build of gcc 4.1.1.

But it works fine with other versions of gcc, and other compilers,
and the operation I want done looks entirely logical to me.

Is this code C90-compliant or not?

No. The result of a cast isn't a lvalue.
see www.c-faq.com, question 4.5