Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <3652@goanna.cs.rmit.oz.au>
Date: 31 Aug 90 07:50:04 GMT
References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <141658@sun.Eng.Sun.COM>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 31

In article <141569@sun.Eng.Sun.COM> lm@sun.UUCP (Larry McVoy) writes:
>  char *bar = (char*)malloc(100);
>    
>  which doesn't work under Rob's machine...

In article <1990Aug30.165552.3875@zoo.toronto.edu> henry@zoo.toronto.edu
(Henry Spencer) writes:
>  Uh, why not?

In article <141658@sun.Eng.Sun.COM>, lm@snafu.Sun.COM (Larry McVoy) writes:
> So, look at that code again.  From the compiler's point of view, we have
> malloc(), a function returning an int, being assigned into a pointer
> (the cast doesn't do squat, the assignment does the same thing).

The trouble was that the original posting failed to make it clear that
there *wasn't* a declaration
	extern char *malloc();
in scope.  I naturally assumed there was, because I thought the point
was "here is something which works now but would be broken by bit addressing".
Well,
	/* default: extern int malloc(); */
	char *p = (char*)malloc(100);
is ALREADY broken and has been broken for some time.
    * 	sizeof (char*) == sizeof (int)	THIS IS NOT A LAW OF C!  IT BREAKS!
Such code already broke about 10 years ago when you moved it to a
machine with 32-bit pointers but 16-bit ints, and yes there _were_ UNIX
machines around that did that.  Losing the top 16 bits of a pointer is a
pretty serious way to break...

-- 
You can lie with statistics ... but not to a statistician.