Mixing
Is creating a pointer one past the end of a non-array pointer not derived from unary operator & undefined...
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
The C++17 standard seems to say that an integer can only be added to a pointer if the pointer is to an array element, or, as a special exception, the pointer is the result of unary operator &:
8.5.6 [expr.add] describing addition to a pointer:
When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the expression P points to element x[i] of an array object x with n elements, the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) element x[i + j] if 0 ≤ i + j ≤ n; otherwise, the behavior is undefined.
This quote includes a non-normative footnote:
An object that is not an array element is considered to belong to a single-element array for this purpose; see 8.5.2.1
which references 8.5.2.1 [expr.unary.op] discussing the unary & operator:
The result of the unary & operator is a pointer to its operand... For purposes of pointer arithmetic (8.5.6) and comparison (8.5.9, 8.5.10), an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T.
The non-normative footnote seems to be slightly misleading, as the section it references describes behavior specific to the result of unary operator &. Nothing appears to permit other pointers (e.g. from non-array new) to be considered single-element arrays.
This seems to suggest:
void f(int a) {
int* z = (new int) + 1; // undefined behavior
int* w = &a + 1; // ok
}
Is this an oversight in the changes made for C++17? Am I missing something? Is there a reason that the "single-element array rule" is only provided specifically for unary operator &?
Note: As specified in the title, this question is specific to C++17. The C standard and prior versions of the C++ standard contained clear normative language that is no longer present. Older, vague questions like this are not relevant.
c++ arrays pointers language-lawyer c++17
asked Jun 18 '18 at 18:40
0x5f3759df0x5f3759df
1,73411624
|
show 3 more comments
The C++17 standard seems to say that an integer can only be added to a pointer if the pointer is to an array element, or, as a special exception, the pointer is the result of unary operator &:
8.5.6 [expr.add] describing addition to a pointer:
When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the expression P points to element x[i] of an array object x with n elements, the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) element x[i + j] if 0 ≤ i + j ≤ n; otherwise, the behavior is undefined.
This quote includes a non-normative footnote:
An object that is not an array element is considered to belong to a single-element array for this purpose; see 8.5.2.1
which references 8.5.2.1 [expr.unary.op] discussing the unary & operator:
The result of the unary & operator is a pointer to its operand... For purposes of pointer arithmetic (8.5.6) and comparison (8.5.9, 8.5.10), an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T.
The non-normative footnote seems to be slightly misleading, as the section it references describes behavior specific to the result of unary operator &. Nothing appears to permit other pointers (e.g. from non-array new) to be considered single-element arrays.
This seems to suggest:
void f(int a) {
int* z = (new int) + 1; // undefined behavior
int* w = &a + 1; // ok
}
Is this an oversight in the changes made for C++17? Am I missing something? Is there a reason that the "single-element array rule" is only provided specifically for unary operator &?
Note: As specified in the title, this question is specific to C++17. The C standard and prior versions of the C++ standard contained clear normative language that is no longer present. Older, vague questions like this are not relevant.
c++ arrays pointers language-lawyer c++17
asked Jun 18 '18 at 18:40
0x5f3759df0x5f3759df
1,73411624
2
"The non-normative footnote seems to be slightly misleading" That's what non-normative notations are for. They explain in plain English something that is detailed more explicitly elsewhere. "Is there a reason that the "single-element array rule" is only provided specifically for unary operator &?" Is there a reason to provide it for something else?
– Nicol Bolas
Jun 18 '18 at 18:43
7
@NicolBolas If you allocate a single object usingnew, you still have a pointer to a single object without using&, as mentioned by OP. The question is whether this rule also applies in this case (or in related cases).
– Holt
Jun 18 '18 at 18:52
4
Looks like an oversight to me, sincep==&*pby definition.
– n.m.
Jun 18 '18 at 19:12
Hm, I personally interpret 8.5.2.1 as: If we take an address this way, then we have... There is nothing mentioned for the else explicitly, so state is yet open. 8.5.6 generalises the matter in the foot note, expanding the one-element-array rule to the else case. The normative expansion -- see @n.m. 's comment...
– Aconcagua
Jul 29 '18 at 4:50
Related: issue 1596
– xskxzr
Aug 30 '18 at 14:56
|
show 3 more comments
The C++17 standard seems to say that an integer can only be added to a pointer if the pointer is to an array element, or, as a special exception, the pointer is the result of unary operator &:
8.5.6 [expr.add] describing addition to a pointer:
When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the expression P points to element x[i] of an array object x with n elements, the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) element x[i + j] if 0 ≤ i + j ≤ n; otherwise, the behavior is undefined.
This quote includes a non-normative footnote:
An object that is not an array element is considered to belong to a single-element array for this purpose; see 8.5.2.1
which references 8.5.2.1 [expr.unary.op] discussing the unary & operator:
The result of the unary & operator is a pointer to its operand... For purposes of pointer arithmetic (8.5.6) and comparison (8.5.9, 8.5.10), an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T.
The non-normative footnote seems to be slightly misleading, as the section it references describes behavior specific to the result of unary operator &. Nothing appears to permit other pointers (e.g. from non-array new) to be considered single-element arrays.
This seems to suggest:
void f(int a) {
int* z = (new int) + 1; // undefined behavior
int* w = &a + 1; // ok
}
Is this an oversight in the changes made for C++17? Am I missing something? Is there a reason that the "single-element array rule" is only provided specifically for unary operator &?
Note: As specified in the title, this question is specific to C++17. The C standard and prior versions of the C++ standard contained clear normative language that is no longer present. Older, vague questions like this are not relevant.
c++ arrays pointers language-lawyer c++17
asked Jun 18 '18 at 18:40
0x5f3759df0x5f3759df
1,73411624
The C++17 standard seems to say that an integer can only be added to a pointer if the pointer is to an array element, or, as a special exception, the pointer is the result of unary operator &:
8.5.6 [expr.add] describing addition to a pointer:
When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the expression P points to element x[i] of an array object x with n elements, the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) element x[i + j] if 0 ≤ i + j ≤ n; otherwise, the behavior is undefined.
This quote includes a non-normative footnote:
An object that is not an array element is considered to belong to a single-element array for this purpose; see 8.5.2.1
which references 8.5.2.1 [expr.unary.op] discussing the unary & operator:
The result of the unary & operator is a pointer to its operand... For purposes of pointer arithmetic (8.5.6) and comparison (8.5.9, 8.5.10), an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T.
The non-normative footnote seems to be slightly misleading, as the section it references describes behavior specific to the result of unary operator &. Nothing appears to permit other pointers (e.g. from non-array new) to be considered single-element arrays.
This seems to suggest:
void f(int a) {
int* z = (new int) + 1; // undefined behavior
int* w = &a + 1; // ok
}
Is this an oversight in the changes made for C++17? Am I missing something? Is there a reason that the "single-element array rule" is only provided specifically for unary operator &?
Note: As specified in the title, this question is specific to C++17. The C standard and prior versions of the C++ standard contained clear normative language that is no longer present. Older, vague questions like this are not relevant.
c++ arrays pointers language-lawyer c++17
c++ arrays pointers language-lawyer c++17
asked Jun 18 '18 at 18:40
0x5f3759df0x5f3759df
1,73411624
asked Jun 18 '18 at 18:40
0x5f3759df0x5f3759df
1,73411624
asked Jun 18 '18 at 18:40
0x5f3759df0x5f3759df
1,73411624
asked Jun 18 '18 at 18:40
0x5f3759df0x5f3759df
1,73411624
asked Jun 18 '18 at 18:40
0x5f3759df0x5f3759df
1,73411624
1,73411624
2
"The non-normative footnote seems to be slightly misleading" That's what non-normative notations are for. They explain in plain English something that is detailed more explicitly elsewhere. "Is there a reason that the "single-element array rule" is only provided specifically for unary operator &?" Is there a reason to provide it for something else?
– Nicol Bolas
Jun 18 '18 at 18:43
7
@NicolBolas If you allocate a single object usingnew, you still have a pointer to a single object without using&, as mentioned by OP. The question is whether this rule also applies in this case (or in related cases).
– Holt
Jun 18 '18 at 18:52
4
Looks like an oversight to me, sincep==&*pby definition.
– n.m.
Jun 18 '18 at 19:12
Hm, I personally interpret 8.5.2.1 as: If we take an address this way, then we have... There is nothing mentioned for the else explicitly, so state is yet open. 8.5.6 generalises the matter in the foot note, expanding the one-element-array rule to the else case. The normative expansion -- see @n.m. 's comment...
– Aconcagua
Jul 29 '18 at 4:50
Related: issue 1596
– xskxzr
Aug 30 '18 at 14:56
|
show 3 more comments
2
"The non-normative footnote seems to be slightly misleading" That's what non-normative notations are for. They explain in plain English something that is detailed more explicitly elsewhere. "Is there a reason that the "single-element array rule" is only provided specifically for unary operator &?" Is there a reason to provide it for something else?
– Nicol Bolas
Jun 18 '18 at 18:43
7
@NicolBolas If you allocate a single object usingnew, you still have a pointer to a single object without using&, as mentioned by OP. The question is whether this rule also applies in this case (or in related cases).
– Holt
Jun 18 '18 at 18:52
4
Looks like an oversight to me, sincep==&*pby definition.
– n.m.
Jun 18 '18 at 19:12
Hm, I personally interpret 8.5.2.1 as: If we take an address this way, then we have... There is nothing mentioned for the else explicitly, so state is yet open. 8.5.6 generalises the matter in the foot note, expanding the one-element-array rule to the else case. The normative expansion -- see @n.m. 's comment...
– Aconcagua
Jul 29 '18 at 4:50
Related: issue 1596
– xskxzr
Aug 30 '18 at 14:56
2
2
"The non-normative footnote seems to be slightly misleading" That's what non-normative notations are for. They explain in plain English something that is detailed more explicitly elsewhere. "Is there a reason that the "single-element array rule" is only provided specifically for unary operator &?" Is there a reason to provide it for something else?
– Nicol Bolas
Jun 18 '18 at 18:43
"The non-normative footnote seems to be slightly misleading" That's what non-normative notations are for. They explain in plain English something that is detailed more explicitly elsewhere. "Is there a reason that the "single-element array rule" is only provided specifically for unary operator &?" Is there a reason to provide it for something else?
– Nicol Bolas
Jun 18 '18 at 18:43
7
7
@NicolBolas If you allocate a single object using
new, you still have a pointer to a single object without using &, as mentioned by OP. The question is whether this rule also applies in this case (or in related cases).– Holt
Jun 18 '18 at 18:52
@NicolBolas If you allocate a single object using
new, you still have a pointer to a single object without using &, as mentioned by OP. The question is whether this rule also applies in this case (or in related cases).– Holt
Jun 18 '18 at 18:52
4
4
Looks like an oversight to me, since
p==&*p by definition.– n.m.
Jun 18 '18 at 19:12
Looks like an oversight to me, since
p==&*p by definition.– n.m.
Jun 18 '18 at 19:12
Hm, I personally interpret 8.5.2.1 as: If we take an address this way, then we have... There is nothing mentioned for the else explicitly, so state is yet open. 8.5.6 generalises the matter in the foot note, expanding the one-element-array rule to the else case. The normative expansion -- see @n.m. 's comment...
– Aconcagua
Jul 29 '18 at 4:50
Hm, I personally interpret 8.5.2.1 as: If we take an address this way, then we have... There is nothing mentioned for the else explicitly, so state is yet open. 8.5.6 generalises the matter in the foot note, expanding the one-element-array rule to the else case. The normative expansion -- see @n.m. 's comment...
– Aconcagua
Jul 29 '18 at 4:50
Related: issue 1596
– xskxzr
Aug 30 '18 at 14:56
Related: issue 1596
– xskxzr
Aug 30 '18 at 14:56
|
show 3 more comments
1 Answer
1
active
oldest
votes
Yes, this appears to be a bug in the standard.
int* z = (new int)+1; // undefined behavior.
int* a = new int;
int* b = a+1; // undefined behavior, same reason as `z`
&*a; // seeming noop, but magically makes `*a` into an array of one element!
int* c = a+1; // defined behavior!
this is pretty ridiculous.
8.5.2.1 [expr.unary.op]
[...] an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T
once "blessed" by 8.5.2.1, the object is an array of one element. If you don't bless it by invoking & at least once, it has never been blessed by 8.5.2.1 and is not an array of one element.
answered Aug 29 '18 at 18:22
Yakk - Adam NevraumontYakk - Adam Nevraumont
189k21199384
1
Every C or C++ Standard has followed C89's tradition of expecting compiler writers to recognize that in cases where some parts of the Standard defines the behavior of some category of actions, some other part says an overlapping general category of actions invokes UB, actions which fall into both categories should be treated in the defined fashion when there is no sensible reason to do otherwise. Compiler writers who recognize that won't need Standards to complicate the specification of the second category by carving out all of the exemptions, and those who don't are unlikely...
– supercat
Aug 29 '18 at 19:19
1
...to produce quality compilers even if the Standards carve out all the needed exemptions. The failure of the Standards to carve out every exemption from rules identifying general categories of UB would not be a defect if they were interpreted as designed.
– supercat
Aug 29 '18 at 19:22
add a 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%2f50915627%2fis-creating-a-pointer-one-past-the-end-of-a-non-array-pointer-not-derived-from-u%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
Yes, this appears to be a bug in the standard.
int* z = (new int)+1; // undefined behavior.
int* a = new int;
int* b = a+1; // undefined behavior, same reason as `z`
&*a; // seeming noop, but magically makes `*a` into an array of one element!
int* c = a+1; // defined behavior!
this is pretty ridiculous.
8.5.2.1 [expr.unary.op]
[...] an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T
once "blessed" by 8.5.2.1, the object is an array of one element. If you don't bless it by invoking & at least once, it has never been blessed by 8.5.2.1 and is not an array of one element.
answered Aug 29 '18 at 18:22
Yakk - Adam NevraumontYakk - Adam Nevraumont
189k21199384
1
Every C or C++ Standard has followed C89's tradition of expecting compiler writers to recognize that in cases where some parts of the Standard defines the behavior of some category of actions, some other part says an overlapping general category of actions invokes UB, actions which fall into both categories should be treated in the defined fashion when there is no sensible reason to do otherwise. Compiler writers who recognize that won't need Standards to complicate the specification of the second category by carving out all of the exemptions, and those who don't are unlikely...
– supercat
Aug 29 '18 at 19:19
1
...to produce quality compilers even if the Standards carve out all the needed exemptions. The failure of the Standards to carve out every exemption from rules identifying general categories of UB would not be a defect if they were interpreted as designed.
– supercat
Aug 29 '18 at 19:22
add a comment |
Yes, this appears to be a bug in the standard.
int* z = (new int)+1; // undefined behavior.
int* a = new int;
int* b = a+1; // undefined behavior, same reason as `z`
&*a; // seeming noop, but magically makes `*a` into an array of one element!
int* c = a+1; // defined behavior!
this is pretty ridiculous.
8.5.2.1 [expr.unary.op]
[...] an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T
once "blessed" by 8.5.2.1, the object is an array of one element. If you don't bless it by invoking & at least once, it has never been blessed by 8.5.2.1 and is not an array of one element.
answered Aug 29 '18 at 18:22
Yakk - Adam NevraumontYakk - Adam Nevraumont
189k21199384
1
Every C or C++ Standard has followed C89's tradition of expecting compiler writers to recognize that in cases where some parts of the Standard defines the behavior of some category of actions, some other part says an overlapping general category of actions invokes UB, actions which fall into both categories should be treated in the defined fashion when there is no sensible reason to do otherwise. Compiler writers who recognize that won't need Standards to complicate the specification of the second category by carving out all of the exemptions, and those who don't are unlikely...
– supercat
Aug 29 '18 at 19:19
1
...to produce quality compilers even if the Standards carve out all the needed exemptions. The failure of the Standards to carve out every exemption from rules identifying general categories of UB would not be a defect if they were interpreted as designed.
– supercat
Aug 29 '18 at 19:22
add a comment |
Yes, this appears to be a bug in the standard.
int* z = (new int)+1; // undefined behavior.
int* a = new int;
int* b = a+1; // undefined behavior, same reason as `z`
&*a; // seeming noop, but magically makes `*a` into an array of one element!
int* c = a+1; // defined behavior!
this is pretty ridiculous.
8.5.2.1 [expr.unary.op]
[...] an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T
once "blessed" by 8.5.2.1, the object is an array of one element. If you don't bless it by invoking & at least once, it has never been blessed by 8.5.2.1 and is not an array of one element.
answered Aug 29 '18 at 18:22
Yakk - Adam NevraumontYakk - Adam Nevraumont
189k21199384
Yes, this appears to be a bug in the standard.
int* z = (new int)+1; // undefined behavior.
int* a = new int;
int* b = a+1; // undefined behavior, same reason as `z`
&*a; // seeming noop, but magically makes `*a` into an array of one element!
int* c = a+1; // defined behavior!
this is pretty ridiculous.
8.5.2.1 [expr.unary.op]
[...] an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T
once "blessed" by 8.5.2.1, the object is an array of one element. If you don't bless it by invoking & at least once, it has never been blessed by 8.5.2.1 and is not an array of one element.
answered Aug 29 '18 at 18:22
Yakk - Adam NevraumontYakk - Adam Nevraumont
189k21199384
edited Aug 29 '18 at 18:34
answered Aug 29 '18 at 18:22
Yakk - Adam NevraumontYakk - Adam Nevraumont
189k21199384
answered Aug 29 '18 at 18:22
Yakk - Adam NevraumontYakk - Adam Nevraumont
189k21199384
answered Aug 29 '18 at 18:22
Yakk - Adam NevraumontYakk - Adam Nevraumont
189k21199384
189k21199384
1
Every C or C++ Standard has followed C89's tradition of expecting compiler writers to recognize that in cases where some parts of the Standard defines the behavior of some category of actions, some other part says an overlapping general category of actions invokes UB, actions which fall into both categories should be treated in the defined fashion when there is no sensible reason to do otherwise. Compiler writers who recognize that won't need Standards to complicate the specification of the second category by carving out all of the exemptions, and those who don't are unlikely...
– supercat
Aug 29 '18 at 19:19
1
...to produce quality compilers even if the Standards carve out all the needed exemptions. The failure of the Standards to carve out every exemption from rules identifying general categories of UB would not be a defect if they were interpreted as designed.
– supercat
Aug 29 '18 at 19:22
add a comment |
1
Every C or C++ Standard has followed C89's tradition of expecting compiler writers to recognize that in cases where some parts of the Standard defines the behavior of some category of actions, some other part says an overlapping general category of actions invokes UB, actions which fall into both categories should be treated in the defined fashion when there is no sensible reason to do otherwise. Compiler writers who recognize that won't need Standards to complicate the specification of the second category by carving out all of the exemptions, and those who don't are unlikely...
– supercat
Aug 29 '18 at 19:19
1
...to produce quality compilers even if the Standards carve out all the needed exemptions. The failure of the Standards to carve out every exemption from rules identifying general categories of UB would not be a defect if they were interpreted as designed.
– supercat
Aug 29 '18 at 19:22
1
1
Every C or C++ Standard has followed C89's tradition of expecting compiler writers to recognize that in cases where some parts of the Standard defines the behavior of some category of actions, some other part says an overlapping general category of actions invokes UB, actions which fall into both categories should be treated in the defined fashion when there is no sensible reason to do otherwise. Compiler writers who recognize that won't need Standards to complicate the specification of the second category by carving out all of the exemptions, and those who don't are unlikely...
– supercat
Aug 29 '18 at 19:19
Every C or C++ Standard has followed C89's tradition of expecting compiler writers to recognize that in cases where some parts of the Standard defines the behavior of some category of actions, some other part says an overlapping general category of actions invokes UB, actions which fall into both categories should be treated in the defined fashion when there is no sensible reason to do otherwise. Compiler writers who recognize that won't need Standards to complicate the specification of the second category by carving out all of the exemptions, and those who don't are unlikely...
– supercat
Aug 29 '18 at 19:19
1
1
...to produce quality compilers even if the Standards carve out all the needed exemptions. The failure of the Standards to carve out every exemption from rules identifying general categories of UB would not be a defect if they were interpreted as designed.
– supercat
Aug 29 '18 at 19:22
...to produce quality compilers even if the Standards carve out all the needed exemptions. The failure of the Standards to carve out every exemption from rules identifying general categories of UB would not be a defect if they were interpreted as designed.
– supercat
Aug 29 '18 at 19:22
add a 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.
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%2f50915627%2fis-creating-a-pointer-one-past-the-end-of-a-non-array-pointer-not-derived-from-u%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
2
"The non-normative footnote seems to be slightly misleading" That's what non-normative notations are for. They explain in plain English something that is detailed more explicitly elsewhere. "Is there a reason that the "single-element array rule" is only provided specifically for unary operator &?" Is there a reason to provide it for something else?
– Nicol Bolas
Jun 18 '18 at 18:43
7
@NicolBolas If you allocate a single object using
new, you still have a pointer to a single object without using&, as mentioned by OP. The question is whether this rule also applies in this case (or in related cases).– Holt
Jun 18 '18 at 18:52
4
Looks like an oversight to me, since
p==&*pby definition.– n.m.
Jun 18 '18 at 19:12
Hm, I personally interpret 8.5.2.1 as: If we take an address this way, then we have... There is nothing mentioned for the else explicitly, so state is yet open. 8.5.6 generalises the matter in the foot note, expanding the one-element-array rule to the else case. The normative expansion -- see @n.m. 's comment...
– Aconcagua
Jul 29 '18 at 4:50
Related: issue 1596
– xskxzr
Aug 30 '18 at 14:56