effect of free()

Charles Marslett chasm at attctc.Dallas.TX.US
Sun Sep 17 09:25:23 AEST 1989


In article <11063 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
> I've now seen at least four such examples posted in this newsgroup.
[With reference to architectures that fail to support access to pointers
after the memory pointed to is deallocated.]

I have seen two inaccurate examples (in that there do not exist, and probably
could not exist) of such -- assuming very poor quality code generation for
Intel 80x86 processors.

Neither could survive an environment with interrupts (and therefore, could
not exist on any OS I know of for the Intel chips).

A third example, for a fictitous processor, does indeed have the same
characteristic, and it may in fact be able to support C.  Without any
details, I would not assert it to be possible, however, and I would be very
inclined to disbelieve any assertion that both a standard version of C (one
that would accept anything like the language we know today) and Unix (or
Multics) could coexist on the machine.

I missed the fourth example.  Sorry :^(.

Would the next poster who wishes to address the issue either provide some
reasonable archtecture (say a tagged one with no registers, only memory, for
example -- I cannot think of another possibility, yet) where comparision of
an invalid pointer to 0 can generate a trap, OR provide evidence that such
a failure would keep the machine from handling the C language.

I would like to lear a bit from the discussion, but it seems to have
degenerated to a "does so, does not, DOES SO, DOES NOT, ...".

This is much like the religous wars between the Mac and IBM folk, or the Atari
and Amiga folk -- lots of useless noise, so far.



More information about the Comp.lang.c mailing list