Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sun-barr!newstop!sun!snafu!lm
From: lm@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <141658@sun.Eng.Sun.COM>
Date: 31 Aug 90 04:56:05 GMT
References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <631@array.UUCP> <225@csinc.UUCP> <1372@svin02.info.win.tue.nl> <141569@sun.Eng.Sun.COM> <1990Aug30.165552.3875@zoo.toronto.edu>
Sender: news@sun.Eng.Sun.COM
Reply-To: lm@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 34

In article <1990Aug30.165552.3875@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <141569@sun.Eng.Sun.COM> lm@sun.UUCP (Larry McVoy) writes:
>>(1)  Unix has reached the age where it has what can be called dusty deck code.
>>     And this code frequently does stuff like
>>
>>	 char *bar = (char*)malloc(100);
>>    
>>    which doesn't work under Rob's machine...
>
>Uh, why not?  C definitely requires that sizes be expressed in bytes; you
>cannot fool with that without breaking great masses of code.  That doesn't
>meant that addressing can't be to the bit.
>-- 
>TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
>OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry

(Love the signature, henry.)

Anyway, the reason why not is so weird you'll die laughing.  Get this:
On the ETA machine, rather than fixing the compiler so that a ++ on a char*
incremented by 8 (bits) instead of one, they shifted bit addresses (the 
natural address of the machine) into byte addresses when they stored them in
pointers.  But they shifted back to bit addresses when shoving a pointer into
an int.  Whay you ask?  God only knows, it certainly seemed weird to me.

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 assignment causes the int to pointer shift.  Too bad, because malloc()
actually returned a pointer, i.e., the shift had already happened.  The
second shift gives you a la la land address.  Bummer.  Braindead system.
The fix is, of course, to declare malloc() before using it.
---
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com