mei on Nostr: nprofile1q…utslx I am trying to find the answer in the standard. So far, I have ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq0cq07ulfyc7y2l8rczk9s36g8j65tq3m6xk9us8hr3ua4ktfmaqqeutslx (nprofile…tslx) I am trying to find the answer in the standard. So far, I have determined that the following similar example isn’t UB:
int bar(int *p) {
int *q = &p[1];
if (!p) {
return 0;
}
return *q;
}
In C23 (or, rather the N3220 draft), in 6.5.4.2 “Address and indirection operators”, paragraph 3:
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. Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator.
int bar(int *p) {
int *q = &p[1];
if (!p) {
return 0;
}
return *q;
}
In C23 (or, rather the N3220 draft), in 6.5.4.2 “Address and indirection operators”, paragraph 3:
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. Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator.