×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Charles Wilt wrote:
On Fri, May 15, 2009 at 3:23 PM, Dan Kimmel wrote:
(In i, "not set" is different than null.)
It is? How?
Don't you get the same MCH3601 error is you try to use
a pointer that has been set to NULL?
If "not set" means to imply declared [non-based] but
uninitialized or not explicitly set, then I believe in most
languages there is no difference. That is because the declared
storage in most languages will be automatically initialized to
*NULL. Outside of that, there is a difference between /not set/ and
/null/, but that requires further explanation...
As I understand, the difference is whether:
_1>_ The pointer was never tagged in a language where a based
pointer is supported. The based storage is just /bytes/ to the
system until a pointer operation identifies some sixteen bytes of
that storage as a pointer; i.e. tags the storage as a pointer
_2>_ The pointer has since /lost/ its tag; i.e. the pointer
was compromised due to update of the 16 byes of storage by an
operation other than pointer set\manipulation
_3>_ The pointer was either initialized as or set to *NULL;
i.e. has a valid tag, but has no value\address.
For each of those three conditions, when an attempt is made to
reference via that pointer, the error msgMCH3601 will occur. So yes
there is actually a difference, and yes the same error will result
irrespective of which origin at the instruction where such a pointer
is referenced in a statement of the programming language.
In the case of memory corruption, the origin for an MCH3601 would
be the loss of tagging due to a non-pointer operation updating the
storage. In that scenario the pointer is considered compromised,
for which its tag is not preserved during the update of its storage.
This is part of the integrity built into the system, whereby a
pointer can not be manipulated by /data/; i.e. only pointer methods
may copy or manipulate pointer data. Data manipulation of pointers
on other operating systems can be an origin for a virus or other
type of nasty problem involving revised /access/ via pointer on
other operating systems. So although in most OS the corruption of
memory by a program is not actually going to be prevented, at least
_on the i_ there is *no worry* that any memory corruption by data
can somehow generate a new pointer [value] for which its new address
or new offset would then address some privileged code or restricted
object.
FWiW a pointer which is otherwise valid\set, one which is both
tagged [and so not compromised], may instead be pointing to a
deleted object. In this case an attempt to reference the object via
that pointer will effect the error msgMCH3402 instead; i.e. the
dreaded /attempt to refer to a destroyed object/. In my experience
the MCH3402 is most often seen in user code whereby a pointer
established for an open file was not reset to *NULL even though the
file was closed [e.g. close done by another program]; i.e. the
temporary object as ODP [the Open Data Path] was deleted as part of
the /close/ action, but the program with itw own copy of the pointer
is left unaware. Possibly just my perception, based on many problem
reports with that condition, which were in fact just user-errors in
most cases.
Regards, Chuck
midrange.com
