Re: Help about the complexity of code

On Jun 8, 8: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:

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.

Precisely.

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

It could break implementations that provide trapping; see above.

Programs that actually *trigger* such trapping are already non-
conforming (they invoke undefined behavior).

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?

While recent versions of Windows do provide such trapping much of the
time, the result of assigning NULL to a pointer is rigged so that it
does trap.
.

Relevant Pages

  • Re: put of access type
    ... I learned that pointer types are ... implementors the freedom to implement access types as something more ... Ada doesn't equate accesses with addresses, ... architectures where all of memory is considered to be one big block ...
    (comp.lang.ada)
  • 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? ... I mean, sure, this doesn't solve stale ... in this case C++ is providing flexibility to implementors ... I think "you don't pay for what ..." ...
    (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: 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)