"Michael N. Moran" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Michael N. Moran" <[EMAIL PROTECTED]> writes:
| > | From info gcc:
| > | | `-fdelete-null-pointer-checks'
| > | Use global dataflow analysis to identify and eliminate useless
| > | checks for null pointers. The compiler assumes that dereferencing
| > | a null pointer would have halted the program. If a pointer is
| > | checked after it has already been dereferenced, it cannot be null.
| > | | The second sentence makes me question the difference between an
| > | actual dereferencing operation and the use of a dereferencing
| > | operator used to convert a pointer to a C++ reference. Clearly
| > | (to me anyway ;-) the conversion case does not actually cause
| > | an access to the object.
| > It is not a conversion. It is a dereference operation that is defined
| > only for non-null operand. No ifs, no buts.
|
| I'm in over my head, but ... (oops there's a but ;-) here goes:
|
| void bar(int& a);
|
| void foo(int* a)
| {
| // dereference: conversion to reference
| // Since there is not necessarily any object access,
| // thus no assured SEGFAULT.
| bar(*a);
SEGFAULT is not a behaviour defined by the language. It is *just* one
form of undefined behaviour. If you execute that function, it might
reformat your harddrive and that woud be fine -- though I know of no
compiler that does that on purpose. But, the point is that your
program in erring in the outer space.
| // dereference: access to object
| // If a is null, then SEGFAULT
| *a = 0;
Again, that may or may not happen.
| }
|
| Sorry to drag this out. I'm sure its just one of those
| "that's the way the language is defined Moran get over it"
| issues, but (no ifs) ...
Indeed.
-- Gaby
