Times like this are when the prominent voices and vendors need to dial up the volume in requesting Rust, where memory errors "simply go away".
- KB On Friday, June 20th, 2025 at 23:58, Charles Mills <[email protected]> wrote: > On Fri, 20 Jun 2025 16:47:29 +0000, Farley, Peter [email protected] > wrote: > > > I would THINK that if an object on a heap is deleted, then a second delete > > request for that same object SHOULD return an error (invalid object address > > at least), which of course the programmer should be checking . . . but > > regardless of checked or not checked, the effect of a second delete SHOULD > > not cause any storage error in any rational heap system of which I can > > conceive. > > > > Was this a custom heap library or some existing standard heap library? > > > There is no return value from a delete so there is no way to check for an > error. I would appreciate an assert or similar. > > This is the utterly vanilla XLC C++/LE heap library. > > If I am reading the docs correctly a bad delete used to throw but now the > behavior is undefined. > > It is my usual practice to follow a delete with setting the pointer to > nullptr (zero). This has two benefits: (1) if one then tries to de-reference > ("use") the pointer one gets an immediate fault rather than whatever the old > address might happen to point to; and (2) a subsequent duplicate delete is a > no-op. (Standard C++ behavior -- delete of a nullptr is a no-op.) I obviously > failed to follow my own practice in this case. (And yes, it's not perfect. A > program might have more than one pointer to an on-heap object.) > > Charles > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
