Article View: comp.std.c++
Article #3785Re: Referencing pointers after delete
From: Steve Clamage
Date: Sat, 23 Mar 1996 08:13
Date: Sat, 23 Mar 1996 08:13
52 lines
3025 bytes
3025 bytes
In article q3@galaxy.ucr.edu, thp@cs.ucr.edu (Tom Payne) writes:
>Steve Clamage (clamage@Eng.Sun.COM) wrote:
>
>: Even if the value of a pointer after its referent was deleted were
>: required to be valid, it is still not possible to write a portable pointer
>: validity checker for C or C++. Example, assuming that it is always safe
>: to read the value of any pointer:
>:
>: void foo(int* p) {
>: // is p valid?
>: }
>: How are you going to determine portably whether p is valid in foo?
>
>By passing it to a checking routine, of course. ;-) Given the curent
>standard, a call to such a routine can elicit undefined behavior in an
>otherwise portable program:
>
> void bar(int*& p) {
> checkOut(p); // p is passed by value to checkOut.
> p = 0;
> }
>
>I don't mean to imply that one can portably detect *all* invalid
>pointers, but with help from the compiler software-based solutions
>can give coverage that is as complete as those based on hardware.
>In either case, it is not particularly helpful that the behavior
>becomes undefined the moment an invalid value is detected.
"Undefined" doesn't mean "halt and catch fire". (Don't you find annoying
the Star Trek convention, from Classic through Voyager, that any trouble
on board results in the computers bursting into flame?) "Undefined" means
portable programs are given no assurances about behavior.
An implementation can provide all the checking it wants, and can provide
hooks to allow others to do the checking. Documentation may provide clever
third parties the information they need to make add-on checkers. Some
ISV's are making quite a nice living doing exactly that.
Pointer validation isn't going to be portable, as I pointed out before.
I don't see any advantage in trying to restrict the kind or form of checking
that systems are allowed to implement. I would applaud a hardware-based
mechanism, and I would resent a programming language standard that made
it non-conforming.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Technical Details
Message-ID:
<4ivdsv$p3p@engnews1.Eng.Sun.COM>Path:
arc1-ca.pugleaf.net!in1.uu.net!bounce-backReferences:
<4iushh$q3@galaxy.ucr.edu>Show Full Headers
Complete Article Headers
From: clamage@Eng.Sun.COM (Steve Clamage) Message-ID: <4ivdsv$p3p@engnews1.Eng.Sun.COM> X-Original-Date: 22 Mar 1996 23:42:23 GMT Path: arc1-ca.pugleaf.net!in1.uu.net!bounce-back Date: 23 Mar 96 08:13:55 GMT Approved: fjh@cs.mu.oz.au Newsgroups: comp.std.c++ Subject: Re: Referencing pointers after delete Organization: Sun Microsystems Inc. References: <4iushh$q3@galaxy.ucr.edu> Reply-To: clamage@Eng.Sun.COM X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUBMVOyzOEDnX0m9pzZAQG3awF/Wfqnp+HmRx6Zi8lTAJGDkr5UgTcgG0Dn g2ZIZPfp0wAig8WqEUAJ4jTNbDOSGSPU =sURP