effect of free()

[Richard O'Keefe]

In article <1989Sep14.145420.5658 at jarvis.csri.toronto.edu>, flaps at dgp.toronto.edu (Alan J Rosenthal) writes:
> % in other words, can "int x; printf("%d\n", x);" dump core?  I would think
> it could.  If it couldn't, that would be bad, because then environments which
> caused an abort in this situation wouldn't be ansi-compliant, and I think that
> aborting on the access of undefined values can be useful for debugging.

I actually had this happen to me in Pascal on a certain machine.  Clever
Hans had written the Pascal equivalent of
	union {
	    int pre_hash;
	    char the_bytes[sizeof (int)];
	} hack;
	int hash;
	... move first few characters of token into hack.the_bytes ...
	hash = hack.pre_hash % MODULUS;
The assumption was that every bit-pattern of the right size was a valid
integer, and on the machine in question that was _not_ true.  This will
give similar trouble on machines with VAX arithmetic (some bit patterns
when considered as floats are "invalid operands" which trap when/if you
touch them) and on machines with IEEE arithmetic and traps enabled (the
IEEE default is _not_ to enable traps!) where some bit patterns (called
Signalling NaNs) trap.

There is however a significant difference between this case and the one
we have been discussing:  these numbers are _born_ invalid; there is no
way to get your hands on them without inherently non-portable hackery.

[BTW: claims about free() and segmented architectures turn out _not_ to
apply to the 80*86: you wouldn't implement if (ptr == 0) by loading ptr
into a segment register because you _can't_ compare segment registers.]