Re: Help about the complexity of code

On Jun 8, 9:44 am, Jeff Lait <torespondisfut...@xxxxxxxxxxx> wrote:
On Jun 8, 1:42 am, Keith H Duggar <dug...@xxxxxxxxxxxx> wrote:
On Jun 7, 10:46 pm, zaim...@xxxxxxxxxxx wrote:
On Jun 7, 7:57 pm, Jeff Lait <torespondisfut...@xxxxxxxxxxx> wrote:
(Speaking of which, anyone know any good reason why delete doesn't set
the pointer passed to NULL? I mean, sure, this doesn't solve stale
pointers elsewhere, but it would clean up a vast percentage of stale
pointer problems)

Because doing so (defining it be NULL) might interfere with or even
render infeasible more sophisticated pointer error trapping schemes.
Note, however, C++ does not prohibit an implementation from setting
it to NULL. (Are you sure none do?)

No, I am not sure none do. I know mine don't. Mind you, it would be
cold comfort if they did, since it would just mean I have an invisible
bug which reveals itself when I port to a platform that doesn't.

Well sure, undefined behavior is platform dependent and a bug is
a bug. And there are those who think that the C++ standard ought
define away all undefined behavior. Thus far, however, they have
not won the debate and C++ (and C) continue to support undefined
behavior. Please consider that this choice (to support undefined
behavior) may have contributed and may continue to contribute to
the widespread success of the C++ (and C) language.

In short, in this case C++ is providing flexibility to implementors
to use more advanced error trapping techniques than just setting it
NULL should they desire. Whether implementors take advantage of the
freedom or not is a matter outside of the C++ language itself.

If it isn't part of the standard, I can't rely on it. The whole
advantage of having pointers auto-null is so one can write stuff
like
delete myData;
without always having to reflexively write:
myData = 0;
in fear of some later code calling delete myData; or relying on NULL
to signify an unassigned pointer.

If my platform did auto-NULL deletes, it would be folly to rely on it,
since
delete myData;
delete myData;
would work fine on my platform, but crash with a double-free on
platform X that decided to take a different implementation.

I've had enough pain in my life from Irix's MIPS processors happily
letting people read/write from NULL pointers.

Setting a deleted pointer to NULL does very little to ameliorate
problems with dangling pointers. Simply put, it is folly to rely
on it whether implemented by reflex or automagic. Instead, there
both are tools (Purify, Valgrind, etc) and design patterns (RAII,
RRID, etc) that serve better.

In this particular case, any half-way competent compiler can figure
out when that proposed ptr = NULL; assignment is no-effect code (when
it is clearly traceable that a valid pointer is written to that
variable before it is read from again), so you still don't pay for
what you don't use:

In some cases it would be easy. In others it would be impossible.

But, in any well written C++ program, someone is *already* NULLing the
pointer by hand after every delete. The only time they don't auto-
Null is when they've done manual code-flow analysis to verify no one
will read from the pointer before the next write... Analysis, which I
suspect, would be better done by said compiler.

Or they design code using established RAII and RRID patterns to
eliminate the need for either compiler automagic or manual code
flow analysis.

And this
change certainly doesn't break any already-conforming programs.

It could break implementations that provide trapping; see above.

I'm quite curious as to what this would consist of. Can you please
give some links to examples? I'd guess they switch the pointer to a
different known value that still triggers a crash on access?

I don't have any good links handy but I can describe one example
from past experiences. Indeed, one need look no further than the
venerable (or perhaps infamous ;-) Intel 80386 (and perhaps most
of the x86 line but I'm not sure on that).

The 80386 had a segmented memory architecture, addressing memory
with a segment:offset pair of two 16-bit words and pointers were
the concatenated 32-bit pair. Given a pointer p = s:o, a call to
free(p) might return the segment s to the system. Any subsequent
attempt to load segment value s into a segment register would be
trapped by the 80386 hardware. Note, value s can come from other
pointers or even a calculation. Thus the 80386 hardware trapping
was segment selector value based not pointer based.

Note also that I said any attempt to load a segment value ie not
only dereference but any attempt to read the pointer value. That
is why even this C++ code

delete p ;
if ( p == 0 )

is undefined because it attempts to compare the value of p which
requires loading the value of p which can trap on such hardware.

KHD

.

Relevant Pages

  • Re: how do you start learning assembly language
    ... > segment selector and an offset within the segment. ... then the linker has to do the relocation. ... change every "Item" (pointer) in each and every image? ... SizeOfOptionalHeader; SizeOfOptionalHeader ...
    (alt.lang.asm)
  • Re: Trap representations
    ... bytes directly (via a general integer register) and not needing to load ... segment register with the segment portion of an invalid pointer, ... Leave the pointer in memory, ...
    (comp.lang.c)
  • Re: Finding out if a struct is in an array of structs
    ... requiring pointer normalisation. ... that something somewhere needs to know what segment it's in. ... "near" pointers only contain an offset. ... The default pointer type depends on the "memory model" used. ...
    (comp.lang.c)
  • Re: 8086 addressing (overlapping segments)
    ... That is, why not concatenate the segment bits with the offset, ... This doesn't work well with C, which lets you make a visible pointer ... BTW, the predominant language at the time was Cobol, then Fortran. ...
    (comp.arch)
  • Re: Highly efficient string reversal code
    ... uninitialised pointer. ... NOTE Possible undefined behavior ranges from ignoring the ... very beginning of a segment. ... standard is specifically designed to allow such an implementation. ...
    (comp.lang.c)