pointer-to-pointer (invalid lvalue in unary `&)

[Lucas Machado]

i'm doing some Linux Kernel hacking for a course i'm currently taking.
there is a pointer to a struct (struct example_struct *ex_ptr) in a .c
that i want to access in a system call. i defined a pointer to a
pointer in the .c:

extern struct example_struct **pointer;

and somewhere in the code i tried:

pointer = &ex_ptr;

and i get this error when trying to compile the kernel:

invalid lvalue in unary `&'

and it points to the line: pointer = &ex_ptr;....any idea why and what
i should do to fix it?

 

[Leor Zolman]

i'm doing some Linux Kernel hacking for a course i'm currently taking.
there is a pointer to a struct (struct example_struct *ex_ptr) in a .c
that i want to access in a system call. i defined a pointer to a
pointer in the .c:

extern struct example_struct **pointer;

and somewhere in the code i tried:

pointer = &ex_ptr;

and i get this error when trying to compile the kernel:

invalid lvalue in unary `&'

and it points to the line: pointer = &ex_ptr;....any idea why and what
i should do to fix it?

From what you've posted, all looks fine. Can you show /exactly/ what the
definition of ex_ptr looks like? Whatever ex_ptr is, it doesn't seem to
have an address associated with it. If it were just the wrong type for
"pointer", I'd have expected the message to spell that out. So my guess is
that "ex_ptr" is actually something like a constant, as weird as that
sounds...
-leor

 

[Martin Ambuhl]

i'm doing some Linux Kernel hacking for a course i'm currently taking.
there is a pointer to a struct (struct example_struct *ex_ptr) in a .c
that i want to access in a system call. i defined a pointer to a
pointer in the .c:

extern struct example_struct **pointer;

and somewhere in the code i tried:

pointer = &ex_ptr;

and i get this error when trying to compile the kernel:

invalid lvalue in unary `&'

and it points to the line: pointer = &ex_ptr;....any idea why and what
i should do to fix it?

You have almost certainly misdiagnosed the problem. Look to the lines
before the one for which the error is reported. Simple things like
missing a ';' on the line before may be such a culprit. Notice the use
of your assignment below, which is fine. (If you had an incorrect use
of 'extern', that would probably lead to a linking error instead).

#include <stdio.h>

struct example_struct
{
int f;
} basestruct = { 0};
struct example_struct *ex_ptr = &basestruct;

int main(void)
{
struct example_struct **pointer;
pointer = &ex_ptr;
(*pointer)->f = 3;
printf("basestruct.f = %d\n", basestruct.f);
printf("ex_ptr->f = %d\n", ex_ptr->f);
printf("(*pointer)->f = %d\n", (*pointer)->f);
return 0;
}


basestruct.f = 3
ex_ptr->f = 3
(*pointer)->f = 3

 

[Chris Fogelklou]

From what you've posted, all looks fine. Can you show /exactly/ what the
definition of ex_ptr looks like? Whatever ex_ptr is, it doesn't seem to
have an address associated with it. If it were just the wrong type for
"pointer", I'd have expected the message to spell that out. So my guess is
that "ex_ptr" is actually something like a constant, as weird as that
sounds...
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

Ditto! How is ex_ptr defined?

Should be something like:
struct example_struct ex_st;
struct example_struct *ex_ptr;
struct example_struct **pointer;

If you simply want the problem to go away to see if it is a compiler error,
try casting it. That would hide any errors that might occur due to the
compiler only... changing your debugging process from finding a syntax error
to figuring out why your computer is crashing

pointer = (struct example_struct **pointer)&ex_ptr;

 

[Richard Heathfield]

Chris Fogelklou wrote:

If you simply want the problem to go away to see if it is a compiler
error,
try casting it.

That doesn't seem very fruitful advice. He'd be better off trying to
understand the type system than trying to learn how to circumvent it.

That would hide any errors that might occur due to the
compiler only... changing your debugging process from finding a syntax
error to figuring out why your computer is crashing

Finding the syntax error is much easier.

pointer = (struct example_struct **pointer)&ex_ptr;

That cast is badly-formed, and requires a diagnostic.

 

[Chris Fogelklou]

That doesn't seem very fruitful advice. He'd be better off trying to

understand the type system than trying to learn how to circumvent it.
Yep.


Finding the syntax error is much easier

Hence the smiley and the statement that he would have to figure out why the
computer is crashing (sarcasm... oops... my bad

That cast is badly-formed, and requires a diagnostic.

Hmm... It compiles on my system... but from the other posts/responses I've
been participating in, I think my system might be broken. Could you please
elaborate?

typedef struct ui_tag {
uint16 i;
uint16 j;
uint16 k;
uint16 l;
} ui_t, *pui_t;

void main(void)
{
struct ui_tag * ptr_ui;
struct ui_tag ** pptr_ui;
struct ui_tag ui = {0,0,0,0};

ptr_ui = &ui;
pptr_ui = (struct ui_tag **)&ptr_ui;
while(1);

}

 

[Richard Heathfield]

Hence the smiley and the statement that he would have to figure out why
the computer is crashing (sarcasm... oops... my bad


Hmm... It compiles on my system...

Really? I'm surprised.

but from the other posts/responses I've
been participating in, I think my system might be broken. Could you
please elaborate?

typedef struct ui_tag {
uint16 i;
uint16 j;
uint16 k;
uint16 l;
} ui_t, *pui_t;

void main(void)

int main(void)

{
struct ui_tag * ptr_ui;
struct ui_tag ** pptr_ui;
struct ui_tag ui = {0,0,0,0};

ptr_ui = &ui;
pptr_ui = (struct ui_tag **)&ptr_ui;

This isn't the same cast.

The one I said was badly-formed was:

struct example_struct ** is a type, so (struct example_struct **) is a
well-formed cast, but (struct example_struct **pointer) is not.

 

[Martin Ambuhl]

Chris Fogelklou wrote:

[Chris Fogelklou wrote, although he suppressed attribution]
[Richard Heathfield wrote, although Chris Fogelklou suppressed attribution]

Hmm... It compiles on my system... but from the other posts/responses I've
been participating in, I think my system might be broken.

Either your system or you coding is broken, if not both. After, you
write code like:

void main(void)

and your compiler seems not to mind. Turn you damn diagnostics back on.
And learn how to quote properly.

 

[Chris Fogelklou]

Chris Fogelklou wrote:

[Chris Fogelklou wrote, although he suppressed attribution]
[Richard Heathfield wrote, although Chris Fogelklou suppressed attribution]

Hmm... It compiles on my system... but from the other posts/responses I've
been participating in, I think my system might be broken.

Either your system or you coding is broken, if not both. After, you
write code like:

void main(void)

and your compiler seems not to mind. Turn you damn diagnostics back on.
And learn how to quote properly.

I have found that this is the wrong group for me to post in.

Richard, now I see the problem. Of course that was a bad cast. I guess I
left that error out when I wrote the code.

Martin, most of my C programming is for an embedded system... if the main
function were ever to return (return value or not), I would be running out
of uninitialized FLASH or RAM... probably a more serious problem, no? I can
see your point, however, if running inside an OS, where the OS checks the
return value.

In any case, I think I will drop completely out of this NG. I am obviously
not familiar enough with the hard and fast ANSI rules...

It's been real.

Chris

 

[CBFalconer]

.... snip ...

I have found that this is the wrong group for me to post in.

Richard, now I see the problem. Of course that was a bad cast.
I guess I left that error out when I wrote the code.

Martin, most of my C programming is for an embedded system...
if the main function were ever to return (return value or not),
I would be running out of uninitialized FLASH or RAM... probably
a more serious problem, no? I can see your point, however, if
running inside an OS, where the OS checks the return value.

In any case, I think I will drop completely out of this NG. I am
obviously not familiar enough with the hard and fast ANSI rules...

On the contrary, lurking and/or participating will make you a
better embedded programmer, because you will write more portable
code that doesn't require revision for every new situation.
However, do grow a set of scabs.

 

[Emmanuel Delahaye]

On the contrary, lurking and/or participating will make you a
better embedded programmer, because you will write more portable
code that doesn't require revision for every new situation.

Agreed. I'm also a programmer for embedded systems, and I have learned a lot
of things by reading (and contributing to) this NG.

 

[Joe Wright]

Chris Fogelklou wrote:
[ snip ]

I have found that this is the wrong group for me to post in.

Richard, now I see the problem. Of course that was a bad cast. I guess I
left that error out when I wrote the code.

Martin, most of my C programming is for an embedded system... if the main
function were ever to return (return value or not), I would be running out
of uninitialized FLASH or RAM... probably a more serious problem, no? I can
see your point, however, if running inside an OS, where the OS checks the
return value.

In any case, I think I will drop completely out of this NG. I am obviously
not familiar enough with the hard and fast ANSI rules...

It's been real.

Chris

You give up too easily. The experts live here. If you only lurk you can
learn things about C that you can't read in your book. If you post
problematic code here you will get a professional code review from
several experts at zero cost. If you feel that pointing out errors in
your code is personally insulting, you need a thicker skin. Hang in
there (here).

 

[Chris Fogelklou]

Chris Fogelklou wrote:
[ snip ]

I have found that this is the wrong group for me to post in.

Richard, now I see the problem. Of course that was a bad cast. I guess I
left that error out when I wrote the code.

Martin, most of my C programming is for an embedded system... if the main
function were ever to return (return value or not), I would be running out
of uninitialized FLASH or RAM... probably a more serious problem, no? I can
see your point, however, if running inside an OS, where the OS checks the
return value.

In any case, I think I will drop completely out of this NG. I am obviously
not familiar enough with the hard and fast ANSI rules...

It's been real.

Chris

You give up too easily. The experts live here. If you only lurk you can
learn things about C that you can't read in your book. If you post
problematic code here you will get a professional code review from
several experts at zero cost. If you feel that pointing out errors in
your code is personally insulting, you need a thicker skin. Hang in
there (here).

K, I'm back...

Actually, I have been lurking, but reluctant to post because I got flamed so
badly the first time.

I have no problem with people pointing out errors in my code. The problem
was that I was simply trying to suggest some help to somebody but wasn't
exactly precise on the wording I chose while responding to people responding
to me and I got pretty eaten for it.

In any case, I have a new topic of conversation... Now I just found out
that our resident compiler expert thinks that casts are needed between void
* and other pointer types (the thing that I thought and got eaten for,
originally.) I don't have the original posts responding to me,
unfortunately, but I need to point out the err in her ways. Can somebody
please respond with where in the ANSI standard it is explicitly, blatantly
stated that this is not the case?

Thanks,

Chris

 

[Chris Fogelklou]

Never mind... I reposted the question... please reply to that one! Thanks!

Chris Fogelklou wrote:
[ snip ]

I have found that this is the wrong group for me to post in.

Richard, now I see the problem. Of course that was a bad cast. I

guess

I

I

can
You give up too easily. The experts live here. If you only lurk you can
learn things about C that you can't read in your book. If you post
problematic code here you will get a professional code review from
several experts at zero cost. If you feel that pointing out errors in
your code is personally insulting, you need a thicker skin. Hang in
there (here).

K, I'm back...

Actually, I have been lurking, but reluctant to post because I got flamed so
badly the first time.

I have no problem with people pointing out errors in my code. The problem
was that I was simply trying to suggest some help to somebody but wasn't
exactly precise on the wording I chose while responding to people responding
to me and I got pretty eaten for it.

In any case, I have a new topic of conversation... Now I just found out
that our resident compiler expert thinks that casts are needed between void
* and other pointer types (the thing that I thought and got eaten for,
originally.) I don't have the original posts responding to me,
unfortunately, but I need to point out the err in her ways. Can somebody
please respond with where in the ANSI standard it is explicitly, blatantly
stated that this is not the case?

Thanks,

Chris

 

[Dan Pop]

In any case, I have a new topic of conversation... Now I just found out
that our resident compiler expert thinks that casts are needed between void
* and other pointer types (the thing that I thought and got eaten for,
originally.) I don't have the original posts responding to me,
unfortunately, but I need to point out the err in her ways. Can somebody
please respond with where in the ANSI standard it is explicitly, blatantly
stated that this is not the case?

If she's really a compiler expert, she should be able to compile the
following code with the compiler in standard C mode:

#include <stdlib.h>

int main()
{
int *p = malloc(sizeof *p);
void *q = p;
return q != p;
}

If the C compiler silently accepts it, then the code doesn't require any
diagnostic. But she might still claim that this is a case of undefined
behaviour (if she's clueful enough, which is probably not the case, if she
insists that casts are needed). So, here are the chapter and verses
covering my program above:

6.5.9 Equality operators
....
5 Otherwise, at least one operand is a pointer. If one operand is
a pointer and the other is a null pointer constant, the null
pointer constant is converted to the type of the pointer. If
one operand is a pointer to an object or incomplete type and the
other is a pointer to a qualified or unqualified version of void,
the former is converted to the type of the latter.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
....

6.5.16.1 Simple assignment

Constraints

1 One of the following shall hold:
....
- one operand is a pointer to an object or incomplete type and
the other is a pointer to a qualified or unqualified version
of void, and the type pointed to by the left has all the
qualifiers of the type pointed to by the right;

Dan

 

[Irrwahn Grausewitz]

K, I'm back...

In any case, I have a new topic of conversation... Now I just found out
that our resident compiler expert thinks that casts are needed between void
* and other pointer types (the thing that I thought and got eaten for,
originally.)

I have no idea who our resident compiler expert might be, but casts
between void* and pointers to object types in either direction are
rarely needed.

One notable exception are variadic functions expecting a pointer to
void, since in this case the compiler cannot reliably tell beforehand
which type of argument will be requested when the function is called:

int i;
printf("%p", &i); /* Undefined behaviour! */
printf("%p", (void *)&i); /* Correct. */

Another (more common) situation is when you want to access a member
of an aggregate or an array element through a void pointer:

struct S { int i; } s;
void *p = &s;
p->i = 42; /* Plain wrong! */
((struct S *)p)->i = 42; /* Correct. */

int a[9];
void *q = a;
q[6] = 42; /* Plain wrong! */
((int *)q)[6] = 42; /* Correct. */

I don't have the original posts responding to me,
unfortunately, but I need to point out the err in her ways. Can somebody
please respond with where in the ANSI standard it is explicitly, blatantly
stated that this is not the case?

Uh, sorry, that where in the standard is stated exactly *what*?

Regards

 

[Chris Fogelklou]

K, I'm back...

In any case, I have a new topic of conversation... Now I just found out
that our resident compiler expert thinks that casts are needed between void
* and other pointer types (the thing that I thought and got eaten for,
originally.)

I have no idea who our resident compiler expert might be, but casts
between void* and pointers to object types in either direction are
rarely needed.

One notable exception are variadic functions expecting a pointer to
void, since in this case the compiler cannot reliably tell beforehand
which type of argument will be requested when the function is called:

int i;
printf("%p", &i); /* Undefined behaviour! */
printf("%p", (void *)&i); /* Correct. */

Another (more common) situation is when you want to access a member
of an aggregate or an array element through a void pointer:

struct S { int i; } s;
void *p = &s;
p->i = 42; /* Plain wrong! */
((struct S *)p)->i = 42; /* Correct. */

int a[9];
void *q = a;
q[6] = 42; /* Plain wrong! */
((int *)q)[6] = 42; /* Correct. */

I don't have the original posts responding to me,
unfortunately, but I need to point out the err in her ways. Can somebody
please respond with where in the ANSI standard it is explicitly, blatantly
stated that this is not the case?

Uh, sorry, that where in the standard is stated exactly *what*?

I love the way people in this NG reply so agressively... OK... let's put
two sentences together... can we?

Chris Fogelklou wrote:
"Now I just found out
that our resident compiler expert thinks that casts are needed between void
* and other pointer types"

Chris Fogelklou wrote:
"I don't have the original posts responding to me,
unfortunately, but I need to point out the err in her ways. Can somebody
please respond with where in the ANSI standard it is explicitly, blatantly
stated that this is not the case?"

Therefore, *what*== "casts are needed between void * and other pointer
types"

The thread continues further below... (see the new thread by me)

 

[Irrwahn Grausewitz]

"Irrwahn Grausewitz" <[email protected]> wrote in message

I love the way people in this NG reply so agressively...

Huh? Which part of "Uh, sorry, ... what?" made you think I was
showing signs of aggressiveness? I just had to ask, because I
failed to make sense of this part of your post, since to me it
seemed to refer to material posted earlier you claimed not even
you have handy.

And I'm not going to decorate my posts with tiny hearts and stars
and the like... ;-) Actually, I'm IMHO already overdoing it with
the smilies.

The thread continues further below... (see the new thread by me)

Yup, found it.

Regards

 

[Chris Fogelklou]

Huh? Which part of "Uh, sorry, ... what?" made you think I was
showing signs of aggressiveness? I just had to ask, because I
failed to make sense of this part of your post, since to me it
seemed to refer to material posted earlier you claimed not even
you have handy.

Sorry... my bad. Thanks for the smilies! ;-)

Won't happen again... still getting my feet wet.

 

[Irrwahn Grausewitz]

"Irrwahn Grausewitz" <[email protected]> wrote in message

Uh, sorry, that where in the standard is stated exactly *what*?
I love the way people in this NG reply so agressively...

Huh? [...]

Sorry... my bad. Thanks for the smilies! ;-)

No need to apologize, I just thought I point it out. And yes,
posting in c.l.c can turn out to be a rough ride.

Won't happen again... still getting my feet wet.

You're lucky if it's only your feet, and if it's only getting wet.
Some people don't post without wearing their fire-proof suits... ;-)

Regards