delete with NULL argument
Mike Rubenstein Phoenix Contract
> Gregory D. Menzel (menz...@gold.tc.umn.edu) wrote:
> > Is it dangerous to delete a NULL pointer? I think I once read that
> > it is OK to do so and simply has no effect, but I want to make sure.
> > Thanks...
> yes
Of course I meant yes, it is OK to do so; it is not dangerous.
--
Mike Rubenstein
Geoffrey Talvola
>> Gregory D. Menzel wrote:
>> > Is it dangerous to delete a NULL pointer? I think I once read that
>> > it is OK to do so and simply has no effect, but I want to make sure.
>> > Thanks...
>
>
Beware! "delete NULL" is guaranteed to be safe; but "delete [] NULL"
is definitely NOT safe for all compilers! I couldn't believe it when
I saw it, but the version of cfront I'm using definitely generates
unsafe code for "delete [] NULL". I wonder whose brilliant idea this
was?
--
- Geoff Talvola
gtal...@bbn.com
Mike Rubenstein Phoenix Contract
Whoops. My mistake. I should have specified that I was talking about C++
compilers. It was foolish of me to assume that everyone would realize
this.
If your compiler does not allow
delete[] NULL;
it is broken and should be replaced.
--
Mike Rubenstein
Matt Austern
> If your compiler does not allow
>
> delete[] NULL;
>
> it is broken and should be replaced.
That's true, but it's also not completely fair. The ARM makes an
explicit guarantee about "delete 0", but not about "delete[] 0". This
was undoubtedly an oversight, and I agree that it's reasonable to
assume that "delete[] 0" should have the same semantics as "delete 0",
but that guarantee just isn't there in the ARM.
I assume that this oversight has been plugged in the latest working
papers. Older compilers, though, ones that were based on the ARM
instead of on any of the Committee's later decisions, can't be faulted
for doing what the ARM says, or for not doing what the ARM doesn't
say.
--
--matt
Matt Landau
>While I certainly would like it to be as clear as possible, I don't think
>there's any reasonable interpretation of the ARM which does not make
> delete[] 0;
>harmless. From 5.3.4:
True, but that's not the point. The point is that cfront (every
version of cfront I ever checked, up to and including 3.0.x) has
a bug in it such that "delete[] p" generates code that dereferences
a null pointer if p is a member of a class with a virtual destructor
and the value of p is currently zero.
Note that delete[] on a literal zero (or NULL), or on a null pointer
whose class type doesn't have a virtual destructor, works just fine.
The problem is that the cfront-generated code stupidly tries to invoke
the dtor, which involves looking into the vtbl, before checking to see
if the vector being deleted is null. It's just a bug, that's all.
The truly appalling thing is that I reported the bug to USL more than
two years ago, and it was never fixed.
Ellis Brover
> it is OK to do so and simply has no effect, but I want to make sure.
It is completely safe to delete a NULL pointer. ARM 5.3.4 says
"Deleting a pointer with the value zero, however, is guaranteed
to be harmless."
Regards,
Ellis.
Mike Rubenstein Phoenix Contract
> > delete[] 0;
> >harmless. From 5.3.4:
I notice that you post my reply, but don't show the original message I was
following up. That message said:
>> If your compiler does not allow
>>
>> delete[] NULL;
>>
>> it is broken and should be replaced.
> That's true, but it's also not completely fair. The ARM makes an
> explicit guarantee about "delete 0", but not about "delete[] 0". This
> was undoubtedly an oversight, and I agree that it's reasonable to
> assume that "delete[] 0" should have the same semantics as "delete 0",
> but that guarantee just isn't there in the ARM.
It boggles the mind (and I can assure you that my mind is not easily boggled)
that you manage to interpret that as saying that some version of C++ is
broken and one should code for this.
Maybe I'm just a little thick today, but I foolishly interpretted
"the ARM makes an explicit guarantee about 'delete 0', but not about
'delete[] 0.'" as saying that the ARM does not make a guarantee about
'delete[] 0' and responded to that.
--
Mike Rubenstein
John Nagle
>Is it dangerous to delete a NULL pointer?
"Deleting a pointer with the value zero, however, is guaranteed to be
harmless". ARM 5.3.4. In fact, it's considered better style to write
delete(p)
than
if (p) delete(p);
Incidentally, in ANSI C, "free(NULL)" is defined to do nothing.
But in K&R C (from the 1978 edition) the suggested implementation of
"free" will NOT work for "free(NULL)". There may still be some UNIX
C implementations out there that don't accept "free(NULL)", which is
why C programmers tend to be cautious about "free" and this sometimes
carries over to "delete".
John Nagle
Paul Johnson
> Gregory D. Menzel (menz...@gold.tc.umn.edu) wrote:
> > Is it dangerous to delete a NULL pointer? I think I once read that
> > it is OK to do so and simply has no effect, but I want to make sure.
> > Thanks...
>
> yes
>
> --
> Mike Rubenstein
>
>
I think the answer is actually no. Deleting a pointer with the value zero is
_not_ dangerous. In fact it is guaranteed to be harmless.
This may have been what Mike meant, but I suppose a bit of clarification can't
hurt.
[=====]-----------------------------------------------------------[=====]
| / | Paul Johnson pj...@transeda.demon.co.uk | \ |
| / | TransEDA Ltd, tel +44 (0)1703 255118 | \ |
| / | Chandlers Ford, fax +44 (0)1703 270278 | \ |
| / | Hants. UK. #include <std.disclaimer.opinions> | \ |
[_____]-----------------------------------------------------------[_____]
David Binderman
>The problem is that the cfront-generated code stupidly tries to invoke
>the dtor, which involves looking into the vtbl, before checking to see
>if the vector being deleted is null. It's just a bug, that's all.
Other compilers have exactly this same bug, even when they are in ARM
compliant mode (ha!). Try using
#define DELETE( p) if (p) delete p
#define DELETE_ARRAY( p) if (p) delete [] p
all over your product source code. Multiply this kind of jiggery pokery
to avoid compiler bugs by 100, and you'll understand why some managers
think that C++ is a fine idea in theory, but the practice lags behind
somewhat.
>The truly appalling thing is that I reported the bug to USL more than
>two years ago, and it was never fixed.
I agree. I've found reporting bugs in cfront to be a waste of time.
I've given up.
If cfront was the only buggy C++ compiler with an apparently non-existant
support group ...
Regards
David C Binderman MSc BSc +44 171 975 4723 d...@lovat.fmrco.com
O-O Analysis & Design, C++, C, UNIX, telecomms, safety critical, compilers ...
Andrew Koenig
> Beware! "delete NULL" is guaranteed to be safe; but "delete [] NULL"
> is definitely NOT safe for all compilers! I couldn't believe it when
> I saw it, but the version of cfront I'm using definitely generates
> unsafe code for "delete [] NULL". I wonder whose brilliant idea this
> was?
The technical term for such a thing is a `bug.'
--
--Andrew Koenig
a...@research.att.com
Geoffrey Talvola
>gtal...@bbn.com (Geoffrey Talvola) writes:
>>
>>Beware! "delete NULL" is guaranteed to be safe; but "delete [] NULL"
>>is definitely NOT safe for all compilers! I couldn't believe it when
>>I saw it, but the version of cfront I'm using definitely generates
>>unsafe code for "delete [] NULL". I wonder whose brilliant idea this
>>was?
>
> If true, the above is a bug in cfront and has nothing to do with
> what the *language* says.
I didn't mean to suggest that the language spec says this; I just
wanted to point out that, practically speaking, you'd better assume
that delete [] <null pointer> is unsafe if you're using cfront, or if
you might ever port to cfront in the future. It's certainly relevant
for me and a large percentage of the readers of this thread.
It a shame that the poor quality of some current C++ compilers forces
people to program for the lowest common denominator. You are forced
to learn by trial and error what the "safe subset" of C++ is that you
can use, given your set of compilers. And then, when you port to a
new platform, more features break, that subset gets smaller, and you
have to go back and change your old code. (Although I have found that
even more of a problem is the inconsistent or downright broken
libraries and their header files that some compilers give you.)
m...@mole-end.matawan.nj.us
> In <3hpl8k$n...@News1.mcs.com> mi...@mcs.com (Mike Young) writes:
>
> >In article <D3yJt...@news.cis.umn.edu>, menz...@gold.tc.umn.edu
> >says...
> >>
> >>Is it dangerous to delete a NULL pointer? I think I once read that
> >>it is OK to do so and simply has no effect, but I want to make sure.
> >>Thanks...
> >try to call the destructor.
> It has nothing to do with the compiler. It *will* not call any
> destructor.
_Unless_ there is a bug ... in which case the compiler is not compliant.
--
(This man's opinions are his own.)
From mole-end Mark Terribile
m...@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
(Training and consulting in C, C++, UNIX, etc.)
Andrew Koenig
> It a shame that the poor quality of some current C++ compilers forces
> people to program for the lowest common denominator.
My experience is that C++ is not particularly unusual in this regard.
--
--Andrew Koenig
a...@research.att.com
David Binderman
>It a shame that the poor quality of some current C++ compilers forces
>people to program for the lowest common denominator.
Only if you are in a multiple compiler environment.
Why not pick one of the better compilers, get it running on all platforms
of interest, then just suffer its bugs ?
Or you could just stick with (ARM C++ minus exceptions minus templates minus inheritance), which is about what I can rely on working across all
compilers right now.
>You are forced
>to learn by trial and error what the "safe subset" of C++ is that you
>can use, given your set of compilers.
There's quite a lot of industry experience about what works in various
compilers, for example folks like Rogue Wave have shell scripts to test
out a compiler for various language features.
Or just ask your local C++ compiler expert.
>And then, when you port to a
>new platform, more features break, that subset gets smaller, and you
>have to go back and change your old code.
Luckily, all vendors I've dealt with say they implement the ARM
spec, and pass all their test suites ;->
>(Although I have found that
>even more of a problem is the inconsistent or downright broken
>libraries and their header files that some compilers give you.)
Well, its true that a few years ago most vendors were shipping K&R libraries
and header files with their C++ compilers, but I hope that
most vendors now know that the ISO C library should be provided with any C++
compiler.
hint: Do you get FILENAME_MAX (sp?) when you #include <stdio.h> ?
Can you do network code from C++ ?
Regards
David C Binderman MSc BSc +44 171 975 4723 d...@lovat.fmrco.com
O-O Analysis & Design, C++, C, UNIX, telecomms, safety critical, compilers ...
find / -name \*.h -exec egrep "define.*NULL.*void" \; -exec rm -f {} \;
Burger / John Adriaan (ISE)
Paul Johnson <pj...@transeda.demon.co.uk> wrote:
>> Gregory D. Menzel (menz...@gold.tc.umn.edu) wrote:
>> > Is it dangerous to delete a NULL pointer? I think I once read that
>> > it is OK to do so and simply has no effect, but I want to make sure.
>> > Thanks...
>
>_not_ dangerous. In fact it is guaranteed to be harmless.
Just a word of warning, however. I have had trouble with one (old) compiler
that couldn't handle
delete [] p;
when p was nil (Borland C 3.1, from memory). Write a quick test to be sure.
John "Who's memory is getting less and less reliable" Burger