Mixing
Is &*NULL well-defined in C?
Clash Royale CLAN TAG#URR8PPP
up vote
21
down vote
favorite
In what version(s) of the C standards (if any) is the following well-defined?
void foo(void)
char *nullPtr = NULL;
&*nullPtr;
Note that I am not assigning the result to anything - the second line is a simple statement.
This should be a question with an obvious answer, but (as seemingly happens way too often on such questions) I have heard just as many people say the answer is "obviously undefined" as "obviously defined".
On a rather related note, what about the following? Should foo produce a read of c?
extern volatile char c;
void bar(void)
volatile char *nonnullptr = &c;
&*nonnullptr;
(C++ version of the same question: Is &*NULL well-defined in C++?)
c language-lawyer
edited 22 hours ago
John Zwinck
139k16163273
asked 22 hours ago
TLW
560217
add a comment |Â
up vote
21
down vote
favorite
In what version(s) of the C standards (if any) is the following well-defined?
void foo(void)
char *nullPtr = NULL;
&*nullPtr;
Note that I am not assigning the result to anything - the second line is a simple statement.
This should be a question with an obvious answer, but (as seemingly happens way too often on such questions) I have heard just as many people say the answer is "obviously undefined" as "obviously defined".
On a rather related note, what about the following? Should foo produce a read of c?
extern volatile char c;
void bar(void)
volatile char *nonnullptr = &c;
&*nonnullptr;
(C++ version of the same question: Is &*NULL well-defined in C++?)
c language-lawyer
edited 22 hours ago
John Zwinck
139k16163273
asked 22 hours ago
TLW
560217
1
@Ben Voigt -- note that OP seems to be interested in which C Standards allow this construct as well-defined and which don't. The linked duplicate does not appear to answer these details.
– David Bowling
22 hours ago
@AJNeufeld - the linked question only address C11, not previous versions of the standard.
– TLW
21 hours ago
@Ben-Voigt - the linked question only address C11, not previous versions of the standard. (My kingdom for a multinotify.)
– TLW
21 hours ago
1
Related: stackoverflow.com/questions/16732788/… (some info about observable behavior of volatile)
– user202729
19 hours ago
add a comment |Â
up vote
21
down vote
favorite
up vote
21
down vote
favorite
In what version(s) of the C standards (if any) is the following well-defined?
void foo(void)
char *nullPtr = NULL;
&*nullPtr;
Note that I am not assigning the result to anything - the second line is a simple statement.
This should be a question with an obvious answer, but (as seemingly happens way too often on such questions) I have heard just as many people say the answer is "obviously undefined" as "obviously defined".
On a rather related note, what about the following? Should foo produce a read of c?
extern volatile char c;
void bar(void)
volatile char *nonnullptr = &c;
&*nonnullptr;
(C++ version of the same question: Is &*NULL well-defined in C++?)
c language-lawyer
edited 22 hours ago
John Zwinck
139k16163273
asked 22 hours ago
TLW
560217
In what version(s) of the C standards (if any) is the following well-defined?
void foo(void)
char *nullPtr = NULL;
&*nullPtr;
Note that I am not assigning the result to anything - the second line is a simple statement.
This should be a question with an obvious answer, but (as seemingly happens way too often on such questions) I have heard just as many people say the answer is "obviously undefined" as "obviously defined".
On a rather related note, what about the following? Should foo produce a read of c?
extern volatile char c;
void bar(void)
volatile char *nonnullptr = &c;
&*nonnullptr;
(C++ version of the same question: Is &*NULL well-defined in C++?)
c language-lawyer
edited 22 hours ago
John Zwinck
139k16163273
asked 22 hours ago
TLW
560217
edited 22 hours ago
John Zwinck
139k16163273
edited 22 hours ago
John Zwinck
139k16163273
edited 22 hours ago
John Zwinck
139k16163273
139k16163273
asked 22 hours ago
TLW
560217
asked 22 hours ago
TLW
560217
asked 22 hours ago
TLW
560217
560217
1
@Ben Voigt -- note that OP seems to be interested in which C Standards allow this construct as well-defined and which don't. The linked duplicate does not appear to answer these details.
– David Bowling
22 hours ago
@AJNeufeld - the linked question only address C11, not previous versions of the standard.
– TLW
21 hours ago
@Ben-Voigt - the linked question only address C11, not previous versions of the standard. (My kingdom for a multinotify.)
– TLW
21 hours ago
1
Related: stackoverflow.com/questions/16732788/… (some info about observable behavior of volatile)
– user202729
19 hours ago
add a comment |Â
1
@Ben Voigt -- note that OP seems to be interested in which C Standards allow this construct as well-defined and which don't. The linked duplicate does not appear to answer these details.
– David Bowling
22 hours ago
@AJNeufeld - the linked question only address C11, not previous versions of the standard.
– TLW
21 hours ago
@Ben-Voigt - the linked question only address C11, not previous versions of the standard. (My kingdom for a multinotify.)
– TLW
21 hours ago
1
Related: stackoverflow.com/questions/16732788/… (some info about observable behavior of volatile)
– user202729
19 hours ago
1
1
@Ben Voigt -- note that OP seems to be interested in which C Standards allow this construct as well-defined and which don't. The linked duplicate does not appear to answer these details.
– David Bowling
22 hours ago
@Ben Voigt -- note that OP seems to be interested in which C Standards allow this construct as well-defined and which don't. The linked duplicate does not appear to answer these details.
– David Bowling
22 hours ago
@AJNeufeld - the linked question only address C11, not previous versions of the standard.
– TLW
21 hours ago
@AJNeufeld - the linked question only address C11, not previous versions of the standard.
– TLW
21 hours ago
@Ben-Voigt - the linked question only address C11, not previous versions of the standard. (My kingdom for a multinotify.)
– TLW
21 hours ago
@Ben-Voigt - the linked question only address C11, not previous versions of the standard. (My kingdom for a multinotify.)
– TLW
21 hours ago
1
1
Related: stackoverflow.com/questions/16732788/… (some info about observable behavior of volatile)
– user202729
19 hours ago
Related: stackoverflow.com/questions/16732788/… (some info about observable behavior of volatile)
– user202729
19 hours ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
37
down vote
accepted
While attempts to dereference a null pointer cause undefined behavior, so *nullPtr is illegal, &*nullPtr is perfectly well-defined. According to footnote 102 in the C11 Draft Standard:
Thus, &*E is equivalent to E (even if E is a null pointer),....
This is a result of the fact that, for the unary & operator (§6.5.3.2 ¶3):
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,....
The C99 Standard has the same language, but this does not appear in the C90 Standard, and my reading of that standard is that &*nullPtr would indeed cause undefined behavior in pre-C99 implementations.
From the C90 Standard (§6.3.2.3):
The result of the unary & (address-of) operator is a pointer to the object or function designated by its operand....
and:
The unary * operator denotes indirection.... If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.
Curiously, I don't see any discussion of this change in the C99 Rationale, though I may just be not finding it.
answered 22 hours ago
David Bowling
8,99731742
4
There are many situations where the C Standard says a general class of actions invoke UB, without bothering to enumerate specific cases where there would be an obvious meaning that quality implementations should recognize. If every compiler to date had treated&*pas yieldingpwithout regard for whetherpis null, the authors of the Standard might not have considered the possibility that an implementation might do otherwise. A difficulty here, I think, is that the Standard lacks terms describe...
– supercat
8 hours ago
2
... what constructs like&structArray[i++].memberorstructArray[i++].member = 2;do with the sub-expressionstructArray[i++].member, and what the result of that action is (before&or=is applied). Evaluation of the sub-expression would read the contents ofmember, and that doesn't happen; ergo, the sub-expression is not "evaluated". Given that the termlvalueis used to refer to the source-code expression, I would say that the expression gets "resolve" to an "lref". While evaluation of*pwhenpis a null pointer would invoke UB, resolving the expression should not.
– supercat
8 hours ago
@supercat -- Are you suggesting that some real implementations (pre-C99) must have treated&*NULLroughly, thus leading the Standards committee to clarify the issue? Interesting comments about sub-expressions; there are cases where expressions are explicitly not to be evaluated, e.g.sizeofexcept for VLAs, and operands tosizeof. I tend to operate under the assumption that all expressions are evaluated unless explicitly exempted by the Standard, but I need to revisit the Standard to see how accurate this position is....
– David Bowling
6 hours ago
1
@supercat -- There is a culture of reading the Standard as uncharitably as possible, as if the DeathStation 9000 could arrive with the Endtimes any day now. Your comments about resolution vs. evaluation remind me of the removal of VLAs from C11: why can't they give us a VLA type to use even if definition of actual VLAs is disallowed?
– David Bowling
6 hours ago
The actual expression&*NULLshould be a constraint violation on many platforms, since the unary operator*cannot accept a a literal zero nor avoid*as an argument. There are many cases where the evaluating the operand of&would yield UB, but the use of&should be defined, such asint i; scanf("%d",&i);. Recognizing that operands may be take types, lrefs, or some take values, and that operators perform as much computation on their operands as needed to produce what they need, would clarify a lot.
– supercat
6 hours ago
 |Â
show 7 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
37
down vote
accepted
While attempts to dereference a null pointer cause undefined behavior, so *nullPtr is illegal, &*nullPtr is perfectly well-defined. According to footnote 102 in the C11 Draft Standard:
Thus, &*E is equivalent to E (even if E is a null pointer),....
This is a result of the fact that, for the unary & operator (§6.5.3.2 ¶3):
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,....
The C99 Standard has the same language, but this does not appear in the C90 Standard, and my reading of that standard is that &*nullPtr would indeed cause undefined behavior in pre-C99 implementations.
From the C90 Standard (§6.3.2.3):
The result of the unary & (address-of) operator is a pointer to the object or function designated by its operand....
and:
The unary * operator denotes indirection.... If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.
Curiously, I don't see any discussion of this change in the C99 Rationale, though I may just be not finding it.
answered 22 hours ago
David Bowling
8,99731742
4
There are many situations where the C Standard says a general class of actions invoke UB, without bothering to enumerate specific cases where there would be an obvious meaning that quality implementations should recognize. If every compiler to date had treated&*pas yieldingpwithout regard for whetherpis null, the authors of the Standard might not have considered the possibility that an implementation might do otherwise. A difficulty here, I think, is that the Standard lacks terms describe...
– supercat
8 hours ago
2
... what constructs like&structArray[i++].memberorstructArray[i++].member = 2;do with the sub-expressionstructArray[i++].member, and what the result of that action is (before&or=is applied). Evaluation of the sub-expression would read the contents ofmember, and that doesn't happen; ergo, the sub-expression is not "evaluated". Given that the termlvalueis used to refer to the source-code expression, I would say that the expression gets "resolve" to an "lref". While evaluation of*pwhenpis a null pointer would invoke UB, resolving the expression should not.
– supercat
8 hours ago
@supercat -- Are you suggesting that some real implementations (pre-C99) must have treated&*NULLroughly, thus leading the Standards committee to clarify the issue? Interesting comments about sub-expressions; there are cases where expressions are explicitly not to be evaluated, e.g.sizeofexcept for VLAs, and operands tosizeof. I tend to operate under the assumption that all expressions are evaluated unless explicitly exempted by the Standard, but I need to revisit the Standard to see how accurate this position is....
– David Bowling
6 hours ago
1
@supercat -- There is a culture of reading the Standard as uncharitably as possible, as if the DeathStation 9000 could arrive with the Endtimes any day now. Your comments about resolution vs. evaluation remind me of the removal of VLAs from C11: why can't they give us a VLA type to use even if definition of actual VLAs is disallowed?
– David Bowling
6 hours ago
The actual expression&*NULLshould be a constraint violation on many platforms, since the unary operator*cannot accept a a literal zero nor avoid*as an argument. There are many cases where the evaluating the operand of&would yield UB, but the use of&should be defined, such asint i; scanf("%d",&i);. Recognizing that operands may be take types, lrefs, or some take values, and that operators perform as much computation on their operands as needed to produce what they need, would clarify a lot.
– supercat
6 hours ago
 |Â
show 7 more comments
up vote
37
down vote
accepted
While attempts to dereference a null pointer cause undefined behavior, so *nullPtr is illegal, &*nullPtr is perfectly well-defined. According to footnote 102 in the C11 Draft Standard:
Thus, &*E is equivalent to E (even if E is a null pointer),....
This is a result of the fact that, for the unary & operator (§6.5.3.2 ¶3):
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,....
The C99 Standard has the same language, but this does not appear in the C90 Standard, and my reading of that standard is that &*nullPtr would indeed cause undefined behavior in pre-C99 implementations.
From the C90 Standard (§6.3.2.3):
The result of the unary & (address-of) operator is a pointer to the object or function designated by its operand....
and:
The unary * operator denotes indirection.... If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.
Curiously, I don't see any discussion of this change in the C99 Rationale, though I may just be not finding it.
answered 22 hours ago
David Bowling
8,99731742
4
There are many situations where the C Standard says a general class of actions invoke UB, without bothering to enumerate specific cases where there would be an obvious meaning that quality implementations should recognize. If every compiler to date had treated&*pas yieldingpwithout regard for whetherpis null, the authors of the Standard might not have considered the possibility that an implementation might do otherwise. A difficulty here, I think, is that the Standard lacks terms describe...
– supercat
8 hours ago
2
... what constructs like&structArray[i++].memberorstructArray[i++].member = 2;do with the sub-expressionstructArray[i++].member, and what the result of that action is (before&or=is applied). Evaluation of the sub-expression would read the contents ofmember, and that doesn't happen; ergo, the sub-expression is not "evaluated". Given that the termlvalueis used to refer to the source-code expression, I would say that the expression gets "resolve" to an "lref". While evaluation of*pwhenpis a null pointer would invoke UB, resolving the expression should not.
– supercat
8 hours ago
@supercat -- Are you suggesting that some real implementations (pre-C99) must have treated&*NULLroughly, thus leading the Standards committee to clarify the issue? Interesting comments about sub-expressions; there are cases where expressions are explicitly not to be evaluated, e.g.sizeofexcept for VLAs, and operands tosizeof. I tend to operate under the assumption that all expressions are evaluated unless explicitly exempted by the Standard, but I need to revisit the Standard to see how accurate this position is....
– David Bowling
6 hours ago
1
@supercat -- There is a culture of reading the Standard as uncharitably as possible, as if the DeathStation 9000 could arrive with the Endtimes any day now. Your comments about resolution vs. evaluation remind me of the removal of VLAs from C11: why can't they give us a VLA type to use even if definition of actual VLAs is disallowed?
– David Bowling
6 hours ago
The actual expression&*NULLshould be a constraint violation on many platforms, since the unary operator*cannot accept a a literal zero nor avoid*as an argument. There are many cases where the evaluating the operand of&would yield UB, but the use of&should be defined, such asint i; scanf("%d",&i);. Recognizing that operands may be take types, lrefs, or some take values, and that operators perform as much computation on their operands as needed to produce what they need, would clarify a lot.
– supercat
6 hours ago
 |Â
show 7 more comments
up vote
37
down vote
accepted
up vote
37
down vote
accepted
While attempts to dereference a null pointer cause undefined behavior, so *nullPtr is illegal, &*nullPtr is perfectly well-defined. According to footnote 102 in the C11 Draft Standard:
Thus, &*E is equivalent to E (even if E is a null pointer),....
This is a result of the fact that, for the unary & operator (§6.5.3.2 ¶3):
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,....
The C99 Standard has the same language, but this does not appear in the C90 Standard, and my reading of that standard is that &*nullPtr would indeed cause undefined behavior in pre-C99 implementations.
From the C90 Standard (§6.3.2.3):
The result of the unary & (address-of) operator is a pointer to the object or function designated by its operand....
and:
The unary * operator denotes indirection.... If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.
Curiously, I don't see any discussion of this change in the C99 Rationale, though I may just be not finding it.
answered 22 hours ago
David Bowling
8,99731742
While attempts to dereference a null pointer cause undefined behavior, so *nullPtr is illegal, &*nullPtr is perfectly well-defined. According to footnote 102 in the C11 Draft Standard:
Thus, &*E is equivalent to E (even if E is a null pointer),....
This is a result of the fact that, for the unary & operator (§6.5.3.2 ¶3):
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,....
The C99 Standard has the same language, but this does not appear in the C90 Standard, and my reading of that standard is that &*nullPtr would indeed cause undefined behavior in pre-C99 implementations.
From the C90 Standard (§6.3.2.3):
The result of the unary & (address-of) operator is a pointer to the object or function designated by its operand....
and:
The unary * operator denotes indirection.... If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.
Curiously, I don't see any discussion of this change in the C99 Rationale, though I may just be not finding it.
answered 22 hours ago
David Bowling
8,99731742
edited 22 hours ago
answered 22 hours ago
David Bowling
8,99731742
answered 22 hours ago
David Bowling
8,99731742
answered 22 hours ago
David Bowling
8,99731742
8,99731742
4
There are many situations where the C Standard says a general class of actions invoke UB, without bothering to enumerate specific cases where there would be an obvious meaning that quality implementations should recognize. If every compiler to date had treated&*pas yieldingpwithout regard for whetherpis null, the authors of the Standard might not have considered the possibility that an implementation might do otherwise. A difficulty here, I think, is that the Standard lacks terms describe...
– supercat
8 hours ago
2
... what constructs like&structArray[i++].memberorstructArray[i++].member = 2;do with the sub-expressionstructArray[i++].member, and what the result of that action is (before&or=is applied). Evaluation of the sub-expression would read the contents ofmember, and that doesn't happen; ergo, the sub-expression is not "evaluated". Given that the termlvalueis used to refer to the source-code expression, I would say that the expression gets "resolve" to an "lref". While evaluation of*pwhenpis a null pointer would invoke UB, resolving the expression should not.
– supercat
8 hours ago
@supercat -- Are you suggesting that some real implementations (pre-C99) must have treated&*NULLroughly, thus leading the Standards committee to clarify the issue? Interesting comments about sub-expressions; there are cases where expressions are explicitly not to be evaluated, e.g.sizeofexcept for VLAs, and operands tosizeof. I tend to operate under the assumption that all expressions are evaluated unless explicitly exempted by the Standard, but I need to revisit the Standard to see how accurate this position is....
– David Bowling
6 hours ago
1
@supercat -- There is a culture of reading the Standard as uncharitably as possible, as if the DeathStation 9000 could arrive with the Endtimes any day now. Your comments about resolution vs. evaluation remind me of the removal of VLAs from C11: why can't they give us a VLA type to use even if definition of actual VLAs is disallowed?
– David Bowling
6 hours ago
The actual expression&*NULLshould be a constraint violation on many platforms, since the unary operator*cannot accept a a literal zero nor avoid*as an argument. There are many cases where the evaluating the operand of&would yield UB, but the use of&should be defined, such asint i; scanf("%d",&i);. Recognizing that operands may be take types, lrefs, or some take values, and that operators perform as much computation on their operands as needed to produce what they need, would clarify a lot.
– supercat
6 hours ago
 |Â
show 7 more comments
4
There are many situations where the C Standard says a general class of actions invoke UB, without bothering to enumerate specific cases where there would be an obvious meaning that quality implementations should recognize. If every compiler to date had treated&*pas yieldingpwithout regard for whetherpis null, the authors of the Standard might not have considered the possibility that an implementation might do otherwise. A difficulty here, I think, is that the Standard lacks terms describe...
– supercat
8 hours ago
2
... what constructs like&structArray[i++].memberorstructArray[i++].member = 2;do with the sub-expressionstructArray[i++].member, and what the result of that action is (before&or=is applied). Evaluation of the sub-expression would read the contents ofmember, and that doesn't happen; ergo, the sub-expression is not "evaluated". Given that the termlvalueis used to refer to the source-code expression, I would say that the expression gets "resolve" to an "lref". While evaluation of*pwhenpis a null pointer would invoke UB, resolving the expression should not.
– supercat
8 hours ago
@supercat -- Are you suggesting that some real implementations (pre-C99) must have treated&*NULLroughly, thus leading the Standards committee to clarify the issue? Interesting comments about sub-expressions; there are cases where expressions are explicitly not to be evaluated, e.g.sizeofexcept for VLAs, and operands tosizeof. I tend to operate under the assumption that all expressions are evaluated unless explicitly exempted by the Standard, but I need to revisit the Standard to see how accurate this position is....
– David Bowling
6 hours ago
1
@supercat -- There is a culture of reading the Standard as uncharitably as possible, as if the DeathStation 9000 could arrive with the Endtimes any day now. Your comments about resolution vs. evaluation remind me of the removal of VLAs from C11: why can't they give us a VLA type to use even if definition of actual VLAs is disallowed?
– David Bowling
6 hours ago
The actual expression&*NULLshould be a constraint violation on many platforms, since the unary operator*cannot accept a a literal zero nor avoid*as an argument. There are many cases where the evaluating the operand of&would yield UB, but the use of&should be defined, such asint i; scanf("%d",&i);. Recognizing that operands may be take types, lrefs, or some take values, and that operators perform as much computation on their operands as needed to produce what they need, would clarify a lot.
– supercat
6 hours ago
4
4
There are many situations where the C Standard says a general class of actions invoke UB, without bothering to enumerate specific cases where there would be an obvious meaning that quality implementations should recognize. If every compiler to date had treated
&*p as yielding p without regard for whether p is null, the authors of the Standard might not have considered the possibility that an implementation might do otherwise. A difficulty here, I think, is that the Standard lacks terms describe...– supercat
8 hours ago
There are many situations where the C Standard says a general class of actions invoke UB, without bothering to enumerate specific cases where there would be an obvious meaning that quality implementations should recognize. If every compiler to date had treated
&*p as yielding p without regard for whether p is null, the authors of the Standard might not have considered the possibility that an implementation might do otherwise. A difficulty here, I think, is that the Standard lacks terms describe...– supercat
8 hours ago
2
2
... what constructs like
&structArray[i++].member or structArray[i++].member = 2; do with the sub-expression structArray[i++].member, and what the result of that action is (before & or = is applied). Evaluation of the sub-expression would read the contents of member, and that doesn't happen; ergo, the sub-expression is not "evaluated". Given that the term lvalue is used to refer to the source-code expression, I would say that the expression gets "resolve" to an "lref". While evaluation of *p when p is a null pointer would invoke UB, resolving the expression should not.– supercat
8 hours ago
... what constructs like
&structArray[i++].member or structArray[i++].member = 2; do with the sub-expression structArray[i++].member, and what the result of that action is (before & or = is applied). Evaluation of the sub-expression would read the contents of member, and that doesn't happen; ergo, the sub-expression is not "evaluated". Given that the term lvalue is used to refer to the source-code expression, I would say that the expression gets "resolve" to an "lref". While evaluation of *p when p is a null pointer would invoke UB, resolving the expression should not.– supercat
8 hours ago
@supercat -- Are you suggesting that some real implementations (pre-C99) must have treated
&*NULL roughly, thus leading the Standards committee to clarify the issue? Interesting comments about sub-expressions; there are cases where expressions are explicitly not to be evaluated, e.g. sizeof except for VLAs, and operands to sizeof. I tend to operate under the assumption that all expressions are evaluated unless explicitly exempted by the Standard, but I need to revisit the Standard to see how accurate this position is....– David Bowling
6 hours ago
@supercat -- Are you suggesting that some real implementations (pre-C99) must have treated
&*NULL roughly, thus leading the Standards committee to clarify the issue? Interesting comments about sub-expressions; there are cases where expressions are explicitly not to be evaluated, e.g. sizeof except for VLAs, and operands to sizeof. I tend to operate under the assumption that all expressions are evaluated unless explicitly exempted by the Standard, but I need to revisit the Standard to see how accurate this position is....– David Bowling
6 hours ago
1
1
@supercat -- There is a culture of reading the Standard as uncharitably as possible, as if the DeathStation 9000 could arrive with the Endtimes any day now. Your comments about resolution vs. evaluation remind me of the removal of VLAs from C11: why can't they give us a VLA type to use even if definition of actual VLAs is disallowed?
– David Bowling
6 hours ago
@supercat -- There is a culture of reading the Standard as uncharitably as possible, as if the DeathStation 9000 could arrive with the Endtimes any day now. Your comments about resolution vs. evaluation remind me of the removal of VLAs from C11: why can't they give us a VLA type to use even if definition of actual VLAs is disallowed?
– David Bowling
6 hours ago
The actual expression
&*NULL should be a constraint violation on many platforms, since the unary operator * cannot accept a a literal zero nor a void* as an argument. There are many cases where the evaluating the operand of & would yield UB, but the use of & should be defined, such as int i; scanf("%d",&i);. Recognizing that operands may be take types, lrefs, or some take values, and that operators perform as much computation on their operands as needed to produce what they need, would clarify a lot.– supercat
6 hours ago
The actual expression
&*NULL should be a constraint violation on many platforms, since the unary operator * cannot accept a a literal zero nor a void* as an argument. There are many cases where the evaluating the operand of & would yield UB, but the use of & should be defined, such as int i; scanf("%d",&i);. Recognizing that operands may be take types, lrefs, or some take values, and that operators perform as much computation on their operands as needed to produce what they need, would clarify a lot.– supercat
6 hours ago
 |Â
show 7 more comments
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f51691357%2fis-null-well-defined-in-c%23new-answer', 'question_page');
);
Post as a guest
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
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
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
1
@Ben Voigt -- note that OP seems to be interested in which C Standards allow this construct as well-defined and which don't. The linked duplicate does not appear to answer these details.
– David Bowling
22 hours ago
@AJNeufeld - the linked question only address C11, not previous versions of the standard.
– TLW
21 hours ago
@Ben-Voigt - the linked question only address C11, not previous versions of the standard. (My kingdom for a multinotify.)
– TLW
21 hours ago
1
Related: stackoverflow.com/questions/16732788/… (some info about observable behavior of volatile)
– user202729
19 hours ago