4 ms·

Could someone please explain how this line: "(* p=* p) & (* q=* q);" "inform[s] the compiler that f2() will never be called with aliasing arguments." Thanks

by thornjm 14y ago

jensnockert 14y ago
If p and q are aliased (pointing to the same location), you would assign twice to the same pointer between two consecutive sequence points, which is undefined in C.
- deleted 14y ago
  [deleted]
cygx 14y ago
In contrast to &&, & does not introduce a sequence point, which makes the expression illegal (ie it will exhibit undefined behavior) if p and q alias: an object may only be modified once between sequence points.
- justincormack 14y ago
  Undefined behaviour yes, but does that really make it illegal? Sure the compiler is allowed to play some AC/DC at this point or other undefined behaviour, but I am not sure that makes it an assertion per se?
  - mjn 14y ago
    That's true, but in many cases of undefined behavior, compilers take the liberty of interpreting it as an assertion. In this case, for example, it's legal for the compiler to assume that p and q don't alias when it sees this expression, because either: 1) they really don't alias, in which case the assumption and subsequent optimization is correct; or 2) they really do alias, but in that case the behavior is undefined, so the compiler's choice to apply "erroneous" optimizations is not prohibited. It's a common approach in C compilers for inferring more optimization-relevant semantics than the language constructs explicitly specify.
  - cygx 14y ago
    How else would you define the legality of a C program? The language specification comes with constraints, and code which violates those will probably fail to compile (eg syntax errors); any other semantic violation (ie when you see 'shall' or 'shall not' outside of a constraint clause) only results in undefined behavior. See also the C99 rationale: "Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior." Undefined behavior only occurs in case of program errors or language extensions, in which case you're not dealing with standard C, but C-with-extensions.
DeepDuh 14y ago
Thanks for asking this. I thought it to be a bit smug of OP not to include an explanation. Like everyone here knows the C specs in and out.

Could someone please explain how this line: "(* p=* p) & (* q=* q);" "inform[s] the compiler that f2() will never be called with aliasing arguments." Thanks

by thornjm 14y ago

Could someone please explain how this line: "(* p=* p) & (* q=* q);" "inform[s] the compiler that f2() will never be called with aliasing arguments." Thanks

jensnockert 14y ago

If p and q are aliased (pointing to the same location), you would assign twice to the same pointer between two consecutive sequence points, which is undefined in C.

deleted 14y ago
[deleted]

cygx 14y ago

In contrast to &&, & does not introduce a sequence point, which makes the expression illegal (ie it will exhibit undefined behavior) if p and q alias: an object may only be modified once between sequence points.

justincormack 14y ago
Undefined behaviour yes, but does that really make it illegal? Sure the compiler is allowed to play some AC/DC at this point or other undefined behaviour, but I am not sure that makes it an assertion per se?
- mjn 14y ago
  That's true, but in many cases of undefined behavior, compilers take the liberty of interpreting it as an assertion. In this case, for example, it's legal for the compiler to assume that p and q don't alias when it sees this expression, because either: 1) they really don't alias, in which case the assumption and subsequent optimization is correct; or 2) they really do alias, but in that case the behavior is undefined, so the compiler's choice to apply "erroneous" optimizations is not prohibited. It's a common approach in C compilers for inferring more optimization-relevant semantics than the language constructs explicitly specify.
- cygx 14y ago
  How else would you define the legality of a C program? The language specification comes with constraints, and code which violates those will probably fail to compile (eg syntax errors); any other semantic violation (ie when you see 'shall' or 'shall not' outside of a constraint clause) only results in undefined behavior. See also the C99 rationale: "Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior." Undefined behavior only occurs in case of program errors or language extensions, in which case you're not dealing with standard C, but C-with-extensions.

DeepDuh 14y ago

Thanks for asking this. I thought it to be a bit smug of OP not to include an explanation. Like everyone here knows the C specs in and out.