David R Tribble <david.tribble@central.beasys.com> writes:

>My primary questions are (still):
>
>1)  Can operator 'delete' throw an exception?
>
>2)  Is this possibility even mentioned in the Standard?

I answered (1) in a previous post.  Regarding (2), the possibility is
implied by the definition of `undefined behaviour' in 1.4 [intro.defs];
it has nothing to do with `delete' as such, since the circumstances
in which the `operator delete ()' function can throw an exception are
also circumstances in which *any* program construct could throw an
exception.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


[ 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                             ]

David R Tribble wrote:
> a)  Contructors and destructors can throw exceptions.
>
> b)  Operator 'new' can throw an exception.  The defined exception is
>     'bad_alloc', which is thrown upon failure to allocate storage for an
>     object.

Yes; IMO correct use of exceptions (exceptions are for
exceptionnal circonstance, but never errors).

>     Presumably 'new' can also throw an exception if it detects a
>     corrupt free store.

If you play with the heap and begging to corrupt the data, you
(obviously) get (practical) undefined behaviour.

Practical undefined behaviour means that there is no way
to predict the behaviour even knowing the details of a
particular implementation.

So yes, throwing might be an eventuallity; formating the
hard disk might be annother one; also that could destroy
the universe.

In practice I think it's not a good idea to throw when
you detect an error; in this case you should try to
break in a debugger if there is one or to save what you
can in some backup files and abort.

> c)  Operator 'new' can be prevented from throwing an exception (using the
>     'new(nothrow)' placement argument).

It can still throw if the case of corrupted dara (even
if it's declaration says the contrary).

> So, my questions are:
>
> 1)  Can operator 'delete' throw an exception if it detects a corrupt free
>     store?

Yes, and do anything it want for the same reasons.

> 2)  If so, can this behavior be disabled, ala 'new(nothrow)'?

It's undefined behaviour; the compiler can do what
it wants. (Not excluding something intelligent.)

If you really care about heap corruption, your application
must be very buggy, isn't it ?  ;->

You should realise that the code of operator new may be
in the heap, so perhaps you have just changed it ?

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)


[ 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                             ]

In article 002b04d0@central.beasys.com, David R Tribble <david.tribble@central.beasys.com> writes:
>According to the Dec'97 CD, ...
>
>1)  Can operator 'delete' throw an exception if it detects a corrupt free
>    store?
>
>2)  If so, can this behavior be disabled, ala 'new(nothrow)'?

The December CD shows all versions of library function "operator delete"
having a throw-specification of "throw()". So the answer is no, these
predefined forms cannot throw any exceptions.

A delete-expression such as
 delete p;
might result in an exception if the destructor for *p throws one,
and a class-specific operator delete is allowed to throw an exception,
as far as I can tell. (But I might have missed a prohibition somewhere.)
---
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                             ]

The question I originally asked was:

> 1)  Can operator 'delete' throw an exception if it detects a corrupt free
>     store?

Andrew Koenig gave the best answer, essentially stating that "Yes it can,
but it's undefined behavior":

> Yes, by slightly convoluted reasoning:
>
>     1. There is no officially sanctioned way of corrupting free store.
>
>     2. Therefore, in order to corrupt free store, a program must have
>        done something that evoked ``undefined behavior.''
>
>     3. Once that has happened, all bets are off -- any operation can
>        potentially throw an exception, regardless of what the standard
>        might say about what it is supposed to do.

I think it's safe to say that this thread can die now.


-- David R. Tribble, david.tribble@central.beasys.com --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David R Tribble <david.tribble@central.beasys.com> writes:

>1)  Can operator 'delete' throw an exception if it detects a corrupt free
>    store?

The only way that operator delete can detect a corrupt free store
is if some prior operation has invoked undefined behaviour.
In that case, all bets are off, and operator delete can do
anything it wants to do.

However, in a strictly conforming program (one that does not invoke
undefined behaviour), the `operator delete()' function cannot throw an
exception.  (Note however that a `delete' _expression_ may invoke a
destructor, and that destructor may throw an exception.)

>2)  If so, can this behavior be disabled, ala 'new(nothrow)'?

The only way to disable this behaviour is to avoid invoking
undefined behaviour in the first place.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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                             ]

I (David R Tribble <david.tribble@central.beasys.com>) wrote:
>> b)  Operator 'new' can throw an exception.  The defined exception is
>>     'bad_alloc', which is thrown upon failure to allocate storage for an
>>     object.
>>
>>     Presumably 'new' can also throw an exception if it detects a
>>     corrupt free store.

Valentin Bonnard <bonnardv@pratique.fr> responded:
>So yes, throwing might be an eventuallity; formating the
>hard disk might be annother one; also that could destroy
>the universe.

Where does the Draft Standard state that this is 'undefined behavior'?
I don't find anything of the sort in section 5.3.4 (5.3.4:16-17,22).

>> c)  Operator 'new' can be prevented from throwing an exception (using the
>>     'new(nothrow)' placement argument).

>It can still throw if the case of corrupted dara (even
>if its declaration says the contrary).

This appears to contradict 5.3.4:18.

>> So, my questions are:
>>
>> 1)  Can operator 'delete' throw an exception if it detects a corrupt free
>>     store?

>Yes, and do anything it want for the same reasons.

Where is this stated?  Section 5.3.5 does not state that 'delete' can throw
an exception.  (5.3.5:2 states that deleting a static object or a non-object
is undefined behavior, but those are different headaches.)

>> 2)  If so, can this behavior be disabled, ala 'new(nothrow)'?

>It's undefined behaviour; the compiler can do what
>it wants. (Not excluding something intelligent.)

Your answer seems to be 'no'.

I see no syntax listed for anything like a 'delete(nothrow)'; although
5.3.4:20 mentions 'placement operator delete', there's no corresponding
syntax shown in 5.3.5:1.

>If you really care about heap corruption, your application
>must be very buggy, isn't it ?  ;->

Perhaps the third-party library I link into my 200-line application is
buggy. :-(

>You should realise that the code of operator new may be
>in the heap, so perhaps you have just changed it ?

Such code (i.e., a function) is never compiled onto the stack or the heap.
An errant pointer or subscript might modify code, though, on systems that
don't write-protect the code segments of running programs.

My primary questions are (still):

1)  Can operator 'delete' throw an exception?

2)  Is this possibility even mentioned in the Standard?

-- David R. Tribble, david.tribble@central.beasys.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                             ]

David R Tribble (david.tribble@central.beasys.com) wrote:

 [ snip ]

: My primary questions are (still):
: 1)  Can operator 'delete' throw an exception?

: 2)  Is this possibility even mentioned in the Standard?

Perhaps you are looking for 18.4.1.1 [lib.new.delete.single]

  void operator delete (void* ptr) throw();

And an override must have the same signature.  Not sure about class
member operator delete.  I remember reading something about a
corrupted heap causing more drastic action, but it may not have
been in the draft.

However, from your sited references, you may be asking if a
delete-expression can result in a throw.  Since it calls a destructor,
it could.

HTH,
John
---
[ 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                             ]

David R Tribble wrote:

> 1)  Can operator 'delete' throw an exception if it detects a corrupt free
>     store?
>

No program can corrupt the free store without invoking undefined
behaviour (admittedly I can only prove this by a lot of hand waving, but
it certainly ought to be true). So if the free store is corrupted
anything can happen, including delete throwing an exception.

> 2)  If so, can this behavior be disabled, ala 'new(nothrow)'?

Only by sticking to code which does not exhibit undefined behaviour.

--
Alan Stokes (alan@rcp.co.uk)
RCP Consultants Ltd
Didcot, UK
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <2.2.32.19970206200249.002b04d0@central.beasys.com> David R Tribble <david.tribble@central.beasys.com> writes:

> 1)  Can operator 'delete' throw an exception if it detects a corrupt free
>     store?

Yes, by slightly convoluted reasoning:

 1. There is no officially sanctioned way of corrupting free store.

 2. Therefore, in order to corrupt free store, a program must have
    done something that evoked ``undefined behavior.''

 3. Once that has happened, all bets are off -- any operation can
    potentially throw an exception, regardless of what the standard
    might say about what it is supposed to do.
--
    --Andrew Koenig
      ark@research.att.com
      http://www.research.att.com/info/ark
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I assume if I can code the delete operator then I sure would throw
exceptions if the operation failed.
Meyers discussed in More Effective C++ the problems with creating
attributes that are not fully constructed during evaluation of
constructors. The guidelines he layed down should be followed so if
the constructor or for that matter the destructor fails, resources are
correctly released.

Jon

David R Tribble <david.tribble@central.beasys.com> wrote:

>According to the Dec'97 CD,

>a)  Contructors and destructors can throw exceptions.

>b)  Operator 'new' can throw an exception.  The defined exception is
>    'bad_alloc', which is thrown upon failure to allocate storage for an
>    object.  Presumably 'new' can also throw an exception if it detects a
>    corrupt free store.

>c)  Operator 'new' can be prevented from throwing an exception (using the
>    'new(nothrow)' placement argument).

>So, my questions are:

>1)  Can operator 'delete' throw an exception if it detects a corrupt free
>    store?

>2)  If so, can this behavior be disabled, ala 'new(nothrow)'?

[ 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                             ]

According to the Dec'97 CD,

a)  Contructors and destructors can throw exceptions.

b)  Operator 'new' can throw an exception.  The defined exception is
    'bad_alloc', which is thrown upon failure to allocate storage for an
    object.  Presumably 'new' can also throw an exception if it detects a
    corrupt free store.

c)  Operator 'new' can be prevented from throwing an exception (using the
    'new(nothrow)' placement argument).

So, my questions are:

1)  Can operator 'delete' throw an exception if it detects a corrupt free
    store?

2)  If so, can this behavior be disabled, ala 'new(nothrow)'?
---
[ 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                             ]