Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Summary: touching numbers can trap too
Message-ID: <2110@munnari.oz.au>
Date: 15 Sep 89 03:51:02 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <1989Sep14.145420.5658@jarvis.csri.toronto.edu>
Sender: news@cs.mu.oz.au
Lines: 30

In article <1989Sep14.145420.5658@jarvis.csri.toronto.edu>, flaps@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.]