Give me one intstance where 'p == NULL' will fail (on that line) and I
will shut up! This is after p=malloc(somesize),free(p) ..
Perhaps there isn't one. I've just tried ILE C on the AS/400, which
was a promising candidate, and it let the test through, in this simple
case.
It might fail in a more complex one, where the freed pointer wasn't
in scope; for example, if I freed a pointer and then passed it to a
function in another t.u. which tested it for null. That's because on
the AS/400 pointers aren't simple addresses. They're 128-bit objects
(for a 64-bit address space) that have to be "materialized" before
they can be used. The AS/400 doesn't use a separate virtual address
space for each process ("job" in OS/400); it uses a single virtual
address space for the entire system, and uses strong pointer typing
and hardware address validation to enforce storage access rules.
Here's what the output of the %p format specifier looks like in ILE
C:
intp is SPP:0000 :1aefQPADEV0001MWW 006945 :174:1:24d4
funcp is PRP:0:24d4
The first is an int pointer, the second a function pointer.
The "materialize pointer" instruction does some sophisticated
checking. For example, the following code will produce a run-time
violation and abort the program (or, if the program is compiled for
debugging, suspend it), sending an operator message to the message
queue of the user who submitted it:
void *voidp;
int (*funcp)(void) = main;
voidp = (void *)funcp;
The AS/400 will not let you convert a function pointer to a void
pointer, even with a cast. It catches that at runtime. That's no
odder than trapping a reference to a free'd pointer; it'd be trivial
for the materialization of the latter, even just to read its value
(and not dereference it), to check to see that it was still valid.
It doesn't require any change to the pointer representation, either.
A sequence of 128 bits may be a valid pointer at one point in a
program's lifetime, and not at another, and the implementation could
detect that if it wanted to. In this case, it appears that the IBM
compiler team decided not to trap this error; but the technology is
there for them to have done so.
And they might, in another revision of the compiler. And that's why
it's stupid to assume that, just because no one can point to such an
implementation today, such an implementation will never exist.
--
Michael Wojcik (e-mail address removed)
They had forgathered enough of course in all the various times; they had
again and again, since that first night at the theatre, been face to face
over their question; but they had never been so alone together as they were
actually alone - their talk hadn't yet been so supremely for themselves.
-- Henry James