<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. Of course "null" is a pretty poor value to use because in general using such a value as a pointer "works", meaning you can access storage (with an offset < x'800') without program interrupt. But of course it would not be the storage that you want to be accessing. That is why in MVS/XA it was decided to make the x'7FFFF000' page not addressable (This is not an architectural statement; it is a z/OS implementation statement). Assigning to that address ensures for AMODE 31 or AMODE 64 that your code will blow up if it uses that address, and that means that the logic error would not escape unnoticed if you exercise that path. Peter Relson z/OS Core Technology Design
