Behavior of & followed by * operator
I have a question about the behavior of the address-of operator followed by a dereference operator.
Let's take a look at the expression &*p
where p
is of type int *
.
The C11 standard (section 6.5.3.2) says:
The unary
&
operator yields the address of its operand. If the operand has type ‘‘
type
’’,
the result has type ‘‘pointer to
type
’’. If the operand is the result of a unary
*
operator,
neither that operator nor the
&
operator is evaluated and the result is as if both were
omitted, except that the constraints on the operators still apply and the result is not an lvalue.
With the footnote:
Thus, &*E is equivalent to E (even if E is a null pointer), and &(E1[E2]) to ((E1)+(E2)). It is always true that if E is a function designator or an lvalue that is a valid operand of the unary & operator, *&E is a function designator or an lvalue equal to E. If *P is an lvalue and T is the name of an object pointer type, *(T)P is an lvalue that has a type compatible with that to which T points. Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime.
It is clear that &*p
has to be equal to p
except that &*p
is not an lvalue.
If we now consider a
with type int[10]
, what type is &*a
?
And should there be a difference between for example sizeof a
and sizeof &*a
?
On the one side if we evaluate &*a
, a
would decay to int *
with the dereference operator it will become int
and with the address-of operator then int *
.
On the other side if &*a
behaves "as if both were omitted" the type should be int[10]
.
A short example reveals that gcc treats the expression different:
#include <stdio.h>
int main(void)
{
int a[10];
printf("%zun%zun", sizeof a, sizeof &*a);
return 0;
}
Output:
40
8
Is this in agreement with the C11 standard?
Maybe it is because the "constraints on the operators still apply" and the operand of the dereference operator has to be a pointer?
c language-lawyer
|
show 12 more comments
I have a question about the behavior of the address-of operator followed by a dereference operator.
Let's take a look at the expression &*p
where p
is of type int *
.
The C11 standard (section 6.5.3.2) says:
The unary
&
operator yields the address of its operand. If the operand has type ‘‘
type
’’,
the result has type ‘‘pointer to
type
’’. If the operand is the result of a unary
*
operator,
neither that operator nor the
&
operator is evaluated and the result is as if both were
omitted, except that the constraints on the operators still apply and the result is not an lvalue.
With the footnote:
Thus, &*E is equivalent to E (even if E is a null pointer), and &(E1[E2]) to ((E1)+(E2)). It is always true that if E is a function designator or an lvalue that is a valid operand of the unary & operator, *&E is a function designator or an lvalue equal to E. If *P is an lvalue and T is the name of an object pointer type, *(T)P is an lvalue that has a type compatible with that to which T points. Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime.
It is clear that &*p
has to be equal to p
except that &*p
is not an lvalue.
If we now consider a
with type int[10]
, what type is &*a
?
And should there be a difference between for example sizeof a
and sizeof &*a
?
On the one side if we evaluate &*a
, a
would decay to int *
with the dereference operator it will become int
and with the address-of operator then int *
.
On the other side if &*a
behaves "as if both were omitted" the type should be int[10]
.
A short example reveals that gcc treats the expression different:
#include <stdio.h>
int main(void)
{
int a[10];
printf("%zun%zun", sizeof a, sizeof &*a);
return 0;
}
Output:
40
8
Is this in agreement with the C11 standard?
Maybe it is because the "constraints on the operators still apply" and the operand of the dereference operator has to be a pointer?
c language-lawyer
3
Someone VTCed as not clear. What is not clear? The question is demonstrating GCC behavior seemingly not complying the standard and asking what is wrong.
– Eugene Sh.
Dec 6 at 16:56
2
I would personally expect the behavior demonstrated by GCC rather than the proposed equivalence. The*a
has a type ofint
, so I would think&(int)anything
to returnint*
.
– Eugene Sh.
Dec 6 at 17:02
1
Your “maybe” sounds spot on.
– Ry-♦
Dec 6 at 17:04
2
a
is an lvalue, but&*a
is not an lvalue.
– Ian Abbott
Dec 6 at 17:07
2
Note: I can compilevoid *p = &a;
, but notvoid *q = &(&*a);
– chux
Dec 6 at 17:12
|
show 12 more comments
I have a question about the behavior of the address-of operator followed by a dereference operator.
Let's take a look at the expression &*p
where p
is of type int *
.
The C11 standard (section 6.5.3.2) says:
The unary
&
operator yields the address of its operand. If the operand has type ‘‘
type
’’,
the result has type ‘‘pointer to
type
’’. If the operand is the result of a unary
*
operator,
neither that operator nor the
&
operator is evaluated and the result is as if both were
omitted, except that the constraints on the operators still apply and the result is not an lvalue.
With the footnote:
Thus, &*E is equivalent to E (even if E is a null pointer), and &(E1[E2]) to ((E1)+(E2)). It is always true that if E is a function designator or an lvalue that is a valid operand of the unary & operator, *&E is a function designator or an lvalue equal to E. If *P is an lvalue and T is the name of an object pointer type, *(T)P is an lvalue that has a type compatible with that to which T points. Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime.
It is clear that &*p
has to be equal to p
except that &*p
is not an lvalue.
If we now consider a
with type int[10]
, what type is &*a
?
And should there be a difference between for example sizeof a
and sizeof &*a
?
On the one side if we evaluate &*a
, a
would decay to int *
with the dereference operator it will become int
and with the address-of operator then int *
.
On the other side if &*a
behaves "as if both were omitted" the type should be int[10]
.
A short example reveals that gcc treats the expression different:
#include <stdio.h>
int main(void)
{
int a[10];
printf("%zun%zun", sizeof a, sizeof &*a);
return 0;
}
Output:
40
8
Is this in agreement with the C11 standard?
Maybe it is because the "constraints on the operators still apply" and the operand of the dereference operator has to be a pointer?
c language-lawyer
I have a question about the behavior of the address-of operator followed by a dereference operator.
Let's take a look at the expression &*p
where p
is of type int *
.
The C11 standard (section 6.5.3.2) says:
The unary
&
operator yields the address of its operand. If the operand has type ‘‘
type
’’,
the result has type ‘‘pointer to
type
’’. If the operand is the result of a unary
*
operator,
neither that operator nor the
&
operator is evaluated and the result is as if both were
omitted, except that the constraints on the operators still apply and the result is not an lvalue.
With the footnote:
Thus, &*E is equivalent to E (even if E is a null pointer), and &(E1[E2]) to ((E1)+(E2)). It is always true that if E is a function designator or an lvalue that is a valid operand of the unary & operator, *&E is a function designator or an lvalue equal to E. If *P is an lvalue and T is the name of an object pointer type, *(T)P is an lvalue that has a type compatible with that to which T points. Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime.
It is clear that &*p
has to be equal to p
except that &*p
is not an lvalue.
If we now consider a
with type int[10]
, what type is &*a
?
And should there be a difference between for example sizeof a
and sizeof &*a
?
On the one side if we evaluate &*a
, a
would decay to int *
with the dereference operator it will become int
and with the address-of operator then int *
.
On the other side if &*a
behaves "as if both were omitted" the type should be int[10]
.
A short example reveals that gcc treats the expression different:
#include <stdio.h>
int main(void)
{
int a[10];
printf("%zun%zun", sizeof a, sizeof &*a);
return 0;
}
Output:
40
8
Is this in agreement with the C11 standard?
Maybe it is because the "constraints on the operators still apply" and the operand of the dereference operator has to be a pointer?
c language-lawyer
c language-lawyer
edited Dec 6 at 17:02
asked Dec 6 at 16:49
Osiris
2,051415
2,051415
3
Someone VTCed as not clear. What is not clear? The question is demonstrating GCC behavior seemingly not complying the standard and asking what is wrong.
– Eugene Sh.
Dec 6 at 16:56
2
I would personally expect the behavior demonstrated by GCC rather than the proposed equivalence. The*a
has a type ofint
, so I would think&(int)anything
to returnint*
.
– Eugene Sh.
Dec 6 at 17:02
1
Your “maybe” sounds spot on.
– Ry-♦
Dec 6 at 17:04
2
a
is an lvalue, but&*a
is not an lvalue.
– Ian Abbott
Dec 6 at 17:07
2
Note: I can compilevoid *p = &a;
, but notvoid *q = &(&*a);
– chux
Dec 6 at 17:12
|
show 12 more comments
3
Someone VTCed as not clear. What is not clear? The question is demonstrating GCC behavior seemingly not complying the standard and asking what is wrong.
– Eugene Sh.
Dec 6 at 16:56
2
I would personally expect the behavior demonstrated by GCC rather than the proposed equivalence. The*a
has a type ofint
, so I would think&(int)anything
to returnint*
.
– Eugene Sh.
Dec 6 at 17:02
1
Your “maybe” sounds spot on.
– Ry-♦
Dec 6 at 17:04
2
a
is an lvalue, but&*a
is not an lvalue.
– Ian Abbott
Dec 6 at 17:07
2
Note: I can compilevoid *p = &a;
, but notvoid *q = &(&*a);
– chux
Dec 6 at 17:12
3
3
Someone VTCed as not clear. What is not clear? The question is demonstrating GCC behavior seemingly not complying the standard and asking what is wrong.
– Eugene Sh.
Dec 6 at 16:56
Someone VTCed as not clear. What is not clear? The question is demonstrating GCC behavior seemingly not complying the standard and asking what is wrong.
– Eugene Sh.
Dec 6 at 16:56
2
2
I would personally expect the behavior demonstrated by GCC rather than the proposed equivalence. The
*a
has a type of int
, so I would think &(int)anything
to return int*
.– Eugene Sh.
Dec 6 at 17:02
I would personally expect the behavior demonstrated by GCC rather than the proposed equivalence. The
*a
has a type of int
, so I would think &(int)anything
to return int*
.– Eugene Sh.
Dec 6 at 17:02
1
1
Your “maybe” sounds spot on.
– Ry-♦
Dec 6 at 17:04
Your “maybe” sounds spot on.
– Ry-♦
Dec 6 at 17:04
2
2
a
is an lvalue, but &*a
is not an lvalue.– Ian Abbott
Dec 6 at 17:07
a
is an lvalue, but &*a
is not an lvalue.– Ian Abbott
Dec 6 at 17:07
2
2
Note: I can compile
void *p = &a;
, but not void *q = &(&*a);
– chux
Dec 6 at 17:12
Note: I can compile
void *p = &a;
, but not void *q = &(&*a);
– chux
Dec 6 at 17:12
|
show 12 more comments
1 Answer
1
active
oldest
votes
Consider that the conversion from array to pointer-to-first-element happens separately and before the application of *
. Although the decision about whether to convert the array to a pointer is not made until the C implementation determines whether it is the operand of sizeof
or &
(per C 2018 6.3.2.1 3), this conversion is not part of the *
operation. Thus, by the time we are examining &*
, the operand must already be a pointer.
Furthermore, a constraint on the operand of the *
operator is that it shall have pointer type (C 2018 6.5.3.2 2). Therefore, the operand must be a pointer, not an array.
The phrasing “the result is as if both were omitted” motivates us to consider what the result would be if both were omitted, but the text goes on to say “except that the constraints on the operators still apply and the result is not an lvalue.” Since the constraints still apply, the operand must be a pointer; it is not logically consistent that the constraint could apply and the operand could be an array that has not been converted to a pointer.
It seems that this actually is the answer. Just because they are omitted does not mean they were never there, and an array type would violate the constraint.
– Osiris
Dec 6 at 17:22
No, it just means that they are not omitted in the array case.
– Eugene Sh.
Dec 6 at 17:23
1
@EugeneSh. They are omitted, but the type of the operand is already a pointer per the constraints. Anyway, since it is an array, it would not matter whether they are omitted, or not (it would always be valid, whether evaluated or not, not like e.g. in the null case).
– Acorn
Dec 6 at 17:29
@Acorn No. Constraints do not change types. Operator evaluation does.
– Eugene Sh.
Dec 6 at 17:30
@EugeneSh "Constraints do not change types. Operator evaluation does." Alternatively, you could say "Operators do." I.e. it is the operator that changes the type, whether or not the operator is evaluated.
– Ian Abbott
Dec 6 at 17:36
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53656118%2fbehavior-of-followed-by-operator%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Consider that the conversion from array to pointer-to-first-element happens separately and before the application of *
. Although the decision about whether to convert the array to a pointer is not made until the C implementation determines whether it is the operand of sizeof
or &
(per C 2018 6.3.2.1 3), this conversion is not part of the *
operation. Thus, by the time we are examining &*
, the operand must already be a pointer.
Furthermore, a constraint on the operand of the *
operator is that it shall have pointer type (C 2018 6.5.3.2 2). Therefore, the operand must be a pointer, not an array.
The phrasing “the result is as if both were omitted” motivates us to consider what the result would be if both were omitted, but the text goes on to say “except that the constraints on the operators still apply and the result is not an lvalue.” Since the constraints still apply, the operand must be a pointer; it is not logically consistent that the constraint could apply and the operand could be an array that has not been converted to a pointer.
It seems that this actually is the answer. Just because they are omitted does not mean they were never there, and an array type would violate the constraint.
– Osiris
Dec 6 at 17:22
No, it just means that they are not omitted in the array case.
– Eugene Sh.
Dec 6 at 17:23
1
@EugeneSh. They are omitted, but the type of the operand is already a pointer per the constraints. Anyway, since it is an array, it would not matter whether they are omitted, or not (it would always be valid, whether evaluated or not, not like e.g. in the null case).
– Acorn
Dec 6 at 17:29
@Acorn No. Constraints do not change types. Operator evaluation does.
– Eugene Sh.
Dec 6 at 17:30
@EugeneSh "Constraints do not change types. Operator evaluation does." Alternatively, you could say "Operators do." I.e. it is the operator that changes the type, whether or not the operator is evaluated.
– Ian Abbott
Dec 6 at 17:36
|
show 1 more comment
Consider that the conversion from array to pointer-to-first-element happens separately and before the application of *
. Although the decision about whether to convert the array to a pointer is not made until the C implementation determines whether it is the operand of sizeof
or &
(per C 2018 6.3.2.1 3), this conversion is not part of the *
operation. Thus, by the time we are examining &*
, the operand must already be a pointer.
Furthermore, a constraint on the operand of the *
operator is that it shall have pointer type (C 2018 6.5.3.2 2). Therefore, the operand must be a pointer, not an array.
The phrasing “the result is as if both were omitted” motivates us to consider what the result would be if both were omitted, but the text goes on to say “except that the constraints on the operators still apply and the result is not an lvalue.” Since the constraints still apply, the operand must be a pointer; it is not logically consistent that the constraint could apply and the operand could be an array that has not been converted to a pointer.
It seems that this actually is the answer. Just because they are omitted does not mean they were never there, and an array type would violate the constraint.
– Osiris
Dec 6 at 17:22
No, it just means that they are not omitted in the array case.
– Eugene Sh.
Dec 6 at 17:23
1
@EugeneSh. They are omitted, but the type of the operand is already a pointer per the constraints. Anyway, since it is an array, it would not matter whether they are omitted, or not (it would always be valid, whether evaluated or not, not like e.g. in the null case).
– Acorn
Dec 6 at 17:29
@Acorn No. Constraints do not change types. Operator evaluation does.
– Eugene Sh.
Dec 6 at 17:30
@EugeneSh "Constraints do not change types. Operator evaluation does." Alternatively, you could say "Operators do." I.e. it is the operator that changes the type, whether or not the operator is evaluated.
– Ian Abbott
Dec 6 at 17:36
|
show 1 more comment
Consider that the conversion from array to pointer-to-first-element happens separately and before the application of *
. Although the decision about whether to convert the array to a pointer is not made until the C implementation determines whether it is the operand of sizeof
or &
(per C 2018 6.3.2.1 3), this conversion is not part of the *
operation. Thus, by the time we are examining &*
, the operand must already be a pointer.
Furthermore, a constraint on the operand of the *
operator is that it shall have pointer type (C 2018 6.5.3.2 2). Therefore, the operand must be a pointer, not an array.
The phrasing “the result is as if both were omitted” motivates us to consider what the result would be if both were omitted, but the text goes on to say “except that the constraints on the operators still apply and the result is not an lvalue.” Since the constraints still apply, the operand must be a pointer; it is not logically consistent that the constraint could apply and the operand could be an array that has not been converted to a pointer.
Consider that the conversion from array to pointer-to-first-element happens separately and before the application of *
. Although the decision about whether to convert the array to a pointer is not made until the C implementation determines whether it is the operand of sizeof
or &
(per C 2018 6.3.2.1 3), this conversion is not part of the *
operation. Thus, by the time we are examining &*
, the operand must already be a pointer.
Furthermore, a constraint on the operand of the *
operator is that it shall have pointer type (C 2018 6.5.3.2 2). Therefore, the operand must be a pointer, not an array.
The phrasing “the result is as if both were omitted” motivates us to consider what the result would be if both were omitted, but the text goes on to say “except that the constraints on the operators still apply and the result is not an lvalue.” Since the constraints still apply, the operand must be a pointer; it is not logically consistent that the constraint could apply and the operand could be an array that has not been converted to a pointer.
answered Dec 6 at 17:12
Eric Postpischil
71k875152
71k875152
It seems that this actually is the answer. Just because they are omitted does not mean they were never there, and an array type would violate the constraint.
– Osiris
Dec 6 at 17:22
No, it just means that they are not omitted in the array case.
– Eugene Sh.
Dec 6 at 17:23
1
@EugeneSh. They are omitted, but the type of the operand is already a pointer per the constraints. Anyway, since it is an array, it would not matter whether they are omitted, or not (it would always be valid, whether evaluated or not, not like e.g. in the null case).
– Acorn
Dec 6 at 17:29
@Acorn No. Constraints do not change types. Operator evaluation does.
– Eugene Sh.
Dec 6 at 17:30
@EugeneSh "Constraints do not change types. Operator evaluation does." Alternatively, you could say "Operators do." I.e. it is the operator that changes the type, whether or not the operator is evaluated.
– Ian Abbott
Dec 6 at 17:36
|
show 1 more comment
It seems that this actually is the answer. Just because they are omitted does not mean they were never there, and an array type would violate the constraint.
– Osiris
Dec 6 at 17:22
No, it just means that they are not omitted in the array case.
– Eugene Sh.
Dec 6 at 17:23
1
@EugeneSh. They are omitted, but the type of the operand is already a pointer per the constraints. Anyway, since it is an array, it would not matter whether they are omitted, or not (it would always be valid, whether evaluated or not, not like e.g. in the null case).
– Acorn
Dec 6 at 17:29
@Acorn No. Constraints do not change types. Operator evaluation does.
– Eugene Sh.
Dec 6 at 17:30
@EugeneSh "Constraints do not change types. Operator evaluation does." Alternatively, you could say "Operators do." I.e. it is the operator that changes the type, whether or not the operator is evaluated.
– Ian Abbott
Dec 6 at 17:36
It seems that this actually is the answer. Just because they are omitted does not mean they were never there, and an array type would violate the constraint.
– Osiris
Dec 6 at 17:22
It seems that this actually is the answer. Just because they are omitted does not mean they were never there, and an array type would violate the constraint.
– Osiris
Dec 6 at 17:22
No, it just means that they are not omitted in the array case.
– Eugene Sh.
Dec 6 at 17:23
No, it just means that they are not omitted in the array case.
– Eugene Sh.
Dec 6 at 17:23
1
1
@EugeneSh. They are omitted, but the type of the operand is already a pointer per the constraints. Anyway, since it is an array, it would not matter whether they are omitted, or not (it would always be valid, whether evaluated or not, not like e.g. in the null case).
– Acorn
Dec 6 at 17:29
@EugeneSh. They are omitted, but the type of the operand is already a pointer per the constraints. Anyway, since it is an array, it would not matter whether they are omitted, or not (it would always be valid, whether evaluated or not, not like e.g. in the null case).
– Acorn
Dec 6 at 17:29
@Acorn No. Constraints do not change types. Operator evaluation does.
– Eugene Sh.
Dec 6 at 17:30
@Acorn No. Constraints do not change types. Operator evaluation does.
– Eugene Sh.
Dec 6 at 17:30
@EugeneSh "Constraints do not change types. Operator evaluation does." Alternatively, you could say "Operators do." I.e. it is the operator that changes the type, whether or not the operator is evaluated.
– Ian Abbott
Dec 6 at 17:36
@EugeneSh "Constraints do not change types. Operator evaluation does." Alternatively, you could say "Operators do." I.e. it is the operator that changes the type, whether or not the operator is evaluated.
– Ian Abbott
Dec 6 at 17:36
|
show 1 more comment
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53656118%2fbehavior-of-followed-by-operator%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
Someone VTCed as not clear. What is not clear? The question is demonstrating GCC behavior seemingly not complying the standard and asking what is wrong.
– Eugene Sh.
Dec 6 at 16:56
2
I would personally expect the behavior demonstrated by GCC rather than the proposed equivalence. The
*a
has a type ofint
, so I would think&(int)anything
to returnint*
.– Eugene Sh.
Dec 6 at 17:02
1
Your “maybe” sounds spot on.
– Ry-♦
Dec 6 at 17:04
2
a
is an lvalue, but&*a
is not an lvalue.– Ian Abbott
Dec 6 at 17:07
2
Note: I can compile
void *p = &a;
, but notvoid *q = &(&*a);
– chux
Dec 6 at 17:12