Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!bu.edu!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!edcastle!aiai!richard
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <3338@skye.ed.ac.uk>
Date: 31 Aug 90 12:17:33 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> <2477@crdos1.crd.ge.COM>
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 18

In article <2477@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:

>| 	 char *bar = (char*)malloc(100);

>  This should work under an ANSI compliant C implementation, what's the
>problem. malloc() takes an arguments in bytes, returns a (void *)
>pointer which may be cast to (char *) correctly.

But many programs that cast malloc() to char * do so because they
don't declare malloc() or #include a file that does.  Thus the result
is assumed to be an integer, and if integer <-> pointer casting isn't
a no-op you lose.

-- Richard
-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin