Re: Help about the complexity of code

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.

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.

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.

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?
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
.

Relevant Pages

  • Re: Help about the complexity of code
    ... Whether implementors take advantage of the ... delete myData; ... to signify an unassigned pointer. ... Programs that actually *trigger* such trapping are already non- ...
    (rec.games.roguelike.development)
  • Re: Seeting malloc pointer to NULL [2] -Totally confused!!!!!
    ... (i.e. *pMyData is of type MYDATA, it is not a pointer anymore). ... Now, you see, mallocis expected to return a pointer to PASSCODE ... You have ppPassCode as function parameter; how can you get a PASSCODE* from ...
    (microsoft.public.vc.language)
  • Re: Seeting malloc pointer to NULL [2] -Totally confused!!!!!
    ... (i.e. *pMyData is of type MYDATA, it is not a pointer anymore). ... Now, you see, mallocis expected to return a pointer to PASSCODE ... You have ppPassCode as function parameter; how can you get a PASSCODE* from ...
    (microsoft.public.vc.language)
  • Re: Help about the complexity of code
    ... the pointer passed to NULL? ... bug which reveals itself when I port to a platform that doesn't. ... delete myData; ... freemight return the segment s to the system. ...
    (rec.games.roguelike.development)
  • Re: Additional resources to understand C better.
    ... Knowledge of assembly language is required for an in depth ... but a char* or void* pointer has a 3-bit offset ... A char* pointer value with a non-zero offset field is a C ... that stuff will differ from platform to platform. ...
    (comp.lang.c)