Re: Pointer equality and dereferencing

Wojtek Lerch wrote:
<kuyper@xxxxxxxxxx> wrote in message
news:1158159629.437407.295420@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Wojtek Lerch wrote:
...
All of this doesn't matter to an implementation that doesn't mind if
those
two pointers have identical behaviour. But it should matter to anybody
who
cares about the difference between a defined behaviour and a behaviour
that
matches your expectation because the implementation didn't bother (or
didn't
know how) to keep track whether it was defined or not.

An implementation that doesn't bother (or doesn't know how) to keep
track, is obliged to always produce the behavior that would apply if it
were defined,

I wouldn't say that it's *obliged* to do it when the behaviour is actually
undefined;

It's obliged to produce the defined behavior, when it is defined. As I
see it, there are two basic ways it can do that: 1) keep track of
whether or not the behavior is defined, and make sure that the defined
behavior is produced when it is defined or 2) lose track of whether or
not the behavior is defined, and produce the behavior that would be
defined, if it were defined, whether or not it actually is defined. Of
course, it's perfectly possible to follow a mixed strategy, and that's
precisely what I'd expect many implementations to do: keep track, but
only when it's not too expensive to do so. "too expensive" is, of
course, a judgement call that will be resolved differently by different
compilers; but that's a QoI issue, not a standard-compliance issue.

Do you see any other way of always producing the defined behavior, when
it is actually defined?

... but if it's defined for one of the two pointers and the
implementation doesn't keep track of the distinction between them, then the
logical consequence is that using the wrong pointer will have the same
result that is defined for the right pointer. But that doesn't change the
fact that the behaviour is actually undefined.

Yes, but the case where it's undefined involves defective source code,
which it's the programmer's responsibility to fix. This particular
source of undefined behavior is both very serious, and normally quite
easily avoided.

I'm only concerned about the case where the behavior is defined. In
that case, the fact that a conforming implementation doesn't keep track
of whether or not the behavior is defined doesn't present a problem
that the programmer needs to worry about. The worst that can happen
when a conforming implementation looses track of whether or not the
behavior is defined, is that it will have to forgo the application of
some optimizations, but that's a QoI detail. Granted - it might be a
very serious detail for a program with performance requirements can't
be met without application of those optimizations, but that's a
different issue, and not one that I think you're making.

.

Relevant Pages

  • Re: Function prologs emitted by VC++ compiler
    ... see ebp being used as a frame pointer reliably. ... there is no hard guarantee that ebp will be used as a frame ... InterlockedIncrementwhere the prolog is optimized away and the ... When do compilers decide to do such prolog optimizations. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: [RFC PATCH 1/4] powerpc 2.6.16-rt17: to build on powerpc w/ RT
    ... current implementation is very optimized to avoid even memory barriers ... although do let me know if you see places where the generic code ... could use any of the optimizations used in powerpc. ... There is an array of 2 of these and a pointer to the ...
    (Linux-Kernel)
  • Re: passing class to a function in c++ - performance question
    ... In practice, usually, passing by pointer vs by reference has the same ... optimizations with references vs optimizations with pointers. ... This also applies to the "register" keyword. ...
    (comp.lang.cpp)