Peter Shenkin said:
> I do agree that it is sensible, semantically, to create all
> pointers in the NULLIFIED state; this might be hard in some cases,
> and there might be gotchas, and there might be times where it's
> just a waste of CPU.
Certainly the waste of CPU was one of the many original reasons why this was
not required in the standard. The waste of CPU is not quite trivial if a large
derived-type array (where the derived type has pointer components) is
allocated.
> Personally, I wouldn't be against initializing all pointers to
> NULL() by default in the Standard; short of this, I think
> a cmdline flag to do this might be useful for debugging, as
> a Q-of-I issue -- though I realize that this is different from
> being able to rely on the behavior.
For debugging it is better, IMO, to initialise all pointers to a special
"undefined" bit pattern (i.e. like -trapuv and the like) where use of this
pattern (usually) leads to a runtime error. The most subtle errors arise
when sometimes a (e.g. stack-allocated) pointer is null on entry, and at
other times can actually hold a valid-looking address - either to dead
(i.e. deallocated) storage or even to an existing variable.
NAGWare f90 did that from the start, and with the -P option gives a sensible
message on failure rather than just a segmentation fault.
Of course there are other bad situations (e.g. a SAVEd pointer is left dangling
- pointing to deallocated memory - and later used) that we don't catch, at
least not at present. Some other systems do that though, e.g. the "purify"
product will do that and much more besides (though it still won't catch a
once-dangling pointer that points to "resurrected" storage, but that is
another story).
Cheers,
--
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
([log in to unmask])
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|