> In assembler, one would ...
> Maybe you cannot do exactly this with C/C++ ...

Very do-able in C. I think a macro that did the free() + the nulling would
be a good thing, especially if that is your installation standard. I might
also add an assert that the pointer was not already NULL. Freeing a null
pointer is I believe legal (and a no-op) but it probably indicates logic
confusion and so it might be a good thing for the macro to check. It would
want to be overridable in a cleanup routine where you wanted to free
"everything" unconditionally.

C++ is a little trickier because the "usual" form of "FREEMAIN" is delete,
which not only frees the storage but also drives the allocated object's
"destructor" (a structured cleanup routine). The problem of copying the
pointer to a suitable temp is very solvable, but a little tricky because the
determination of "what destructor" is partially made at compile time, so

MyObject *foo = new MyObject;
void *bar = foo;
delete bar;

does not drive the MyObject destructor, because bar is a void*, not a
MyObject*. (Solvable with templates and/or auto.)

Apologies -- getting kind of OT for an assembler list, although it does tend
to be something of a language and hardware architecture list. 

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]]
On Behalf Of Peter Relson
Sent: Thursday, September 10, 2020 6:03 AM
To: [email protected]
Subject: Re: Deep Cuts

<snip>
Failing to assign NULL to a pointer after you've done a FREE(), fails the 
code review. 
</snip>

If your routine has what z/OS might consider "recovery" (or perhaps 
exception handling) one might easily argue that assigning after the FREE 
is the wrong approach, because the FREE might fail (and route control to 
the exception handling where you might conceivably try using the pointer) 
yet you know you don't want to use that pointer any longer.

In assembler, one would
-- copy the pointer to a temp
-- assign null to the pointer
-- do the free using the temp
so that the pointer is null whether or not the system had a problem with 
the free. That also lets you check "is it null" before trying the free and 
avoid trying a second free if the first had failed (a double free can be 
really bad if some other process has happened to have obtained that same 
storage). Maybe you cannot do exactly this with C/C++, but I'm sure you 
get the idea.

Reply via email to