Kevin Mullin <kmullin@oz.net> writes:

>What is the standard operation of the delete operator when it is given
>an address NOT provided by the new operator?

That is undefined behaviour.

>According to IBM (we are
>using their IBM C/C++ for MVS/ESA product, V3R2M0) it is stated in the
>proposed ANSI standard for C++ as undefined.

That is correct.

>I think it is a problem that the reaction of delete to this situation
>is undefined.

The solution to your dilemma comes from a different part of the C++
draft working paper, which says that an implementation must not
assume anything about replacable functions other than their required
behaviour.   Hmmm, well I _thought_ there was such a statement in
the draft -- but I can't seem to find it.  That statement, if present,
would render the IBM implementation non-conforming, presuming that
the functions calling delete with an invalid address are part of its
standard C++ library.  (If the functions that have that undesirable
behaviour are part of a non-standard library, then there is nothing that
the C++ standard could do about it.)

Does anyone know if my recollection is correct?
Was there such a statement in a previous draft?
It is still there?  If so, where, and if not, why not?

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

Kevin Mullin wrote:
>
> What is the standard operation of the delete operator when it is given
> an address NOT provided by the new operator?  According to IBM (we are
> using their IBM C/C++ for MVS/ESA product, V3R2M0) it is stated in the
> proposed ANSI standard for C++ as undefined.  I think it is a problem
> that the reaction of delete to this situation is undefined.  Let me
> explain my dilemma.

The operation of delete on addresses not provided by the new operator is
and should be undefined. If any code is calling delete with a bad
address, that code is buggy, and should be fixed.

>
> We are overloading new and delete and a global level.  We are doing this
> because in IBM's implementation of C/C++ for MVS, the performance of the
> module is very slow due to an extremely large amount of activity with
> internal HEAP management routines, a response to the new operator.  To
> get better performance, we have overloaded the new and delete operators
> globally.  But, in our implementation, we have discovered that modules
> are giving the delete operators bad addresses.  I.E., addresses that

Whose code was giving your delete operators bad addresses? Yours or
IBM's? You can't find out with a debugging printf(), but it should be
trivial to find out if you use a debugger to run your code. If it is
IBM's, I think you have legitimate cause for complaint.
---
[ 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                             ]

What is the standard operation of the delete operator when it is given
an address NOT provided by the new operator?  According to IBM (we are
using their IBM C/C++ for MVS/ESA product, V3R2M0) it is stated in the
proposed ANSI standard for C++ as undefined.  I think it is a problem
that the reaction of delete to this situation is undefined.  Let me
explain my dilemma.

We are overloading new and delete and a global level.  We are doing this
because in IBM's implementation of C/C++ for MVS, the performance of the
module is very slow due to an extremely large amount of activity with
internal HEAP management routines, a response to the new operator.  To
get better performance, we have overloaded the new and delete operators
globally.  But, in our implementation, we have discovered that modules
are giving the delete operators bad addresses.  I.E., addresses that
were not given by the new operator.  When we run with the provided new
and delete operators, there are no problems, but there is also slow
performance.  When we run with our overloaded new and delete operators,
operation is speeded up by 20%, but we trap instances of bad addresses
being given to delete.  We have decided to ignore these bad address
requests, as our testing has proven out that that is what IBM's
implementation must be doing.  (They won't say.  They say its
proprietary information.)  I believe this is evidence of a memory leak
that has gone unnoticed until now.

Now, the C++ standard gives the ability to overload new and delete.
But, and here's the problem, what is being done in the case of bad
addresses being given to delete is left undefined.  When one is
overloading new and delete, and in so doing one is attempting to mimic
actual operation of new and delete (but do it faster by taking
shortcuts), it is unclear about what to do when bad addresses are
given.  Also, if a client is trying to delete something but is giving a
bad address of that something, then nothing is actually being deleted.
The client believes that something HAS been delete though.  This seems
to define a memory leak potential.

I would love to see some discussion on this topic, as I am trying to
badger IBM into giving more concrete information on what they are doing
in this instance.  All they do is quote the proposed ANSI standard and
say it is undefined, and they don't have to tell us what THEY are
doing.  Very frustrating.

Comments?

--
Kevin Mullin
kmullin@oz.net
---
[ 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                             ]

Kevin Mullin wrote:
[snip]
> To
> get better performance, we have overloaded the new and delete operators
> globally.  But, in our implementation, we have discovered that modules
> are giving the delete operators bad addresses.  I.E., addresses that
> were not given by the new operator.

So there is a bug somewhere, right ?

>                                     When we run with the provided new
> and delete operators, there are no problems, but there is also slow
> performance.

'no problems' might be due to some defensive programming from the
implementors of freestore management (possibly to cope with
back-compatibility issues, etc.)

> When we run with our overloaded new and delete operators,
> operation is speeded up by 20%, but we trap instances of bad addresses
> being given to delete.  We have decided to ignore these bad address
> requests, as our testing has proven out that that is what IBM's
> implementation must be doing.

This is wrong. As I understand it you have evidence that the code
doesn't behave properly. Fix the bug.

>                               (They won't say.  They say its
> proprietary information.)  I believe this is evidence of a memory leak
> that has gone unnoticed until now.
>
> Now, the C++ standard gives the ability to overload new and delete.
> But, and here's the problem, what is being done in the case of bad
> addresses being given to delete is left undefined.  When one is
> overloading new and delete, and in so doing one is attempting to mimic
> actual operation of new and delete (but do it faster by taking
> shortcuts), it is unclear about what to do when bad addresses are
> given.

IMHO the point is making sure that bad adresses are never given.

>        Also, if a client is trying to delete something but is giving a
> bad address of that something, then nothing is actually being deleted.
> The client believes that something HAS been delete though.  This seems
> to define a memory leak potential.
>

or a hard disk reformatting potential. or a running nethack potential.
this is really what `undefined behavior' is about.

> I would love to see some discussion on this topic, as I am trying to
> badger IBM into giving more concrete information on what they are doing
> in this instance.  All they do is quote the proposed ANSI standard and
> say it is undefined, and they don't have to tell us what THEY are
> doing.  Very frustrating.
>
> Comments?
>

Unless there is a compelling reason to mimic the behavior of
the native manager (and I can't figure one) I believe you should
investigate the errors observed. If the cause resides in modifiable
code then fix it. If it originates from a commercial library (which
could explain the `defensive behavior' of the native freestore
manager) then complain to the vendor since a comforming compiler
must allow you to provide your own freestore management routines.
---
[ 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
]