Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!svin02!rcpieter
From: rcpieter@svin02.info.win.tue.nl (Tiggr)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <1374@svin02.info.win.tue.nl>
Date: 30 Aug 90 20:00:32 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>
Followup-To: comp.lang.c
Organization: Eindhoven University of Technology, The Netherlands
Lines: 26

lm@sun.UUCP (Larry McVoy) writes:

|     And this code frequently does stuff like
|
|	 char *bar = (char*)malloc(100);
|    
|    which doesn't work under Rob's machine...

peter@ficc.ferranti.com (Peter da Silva) writes:

|It won't work on *any* machine where sizeof(int) != sizeof(char*), or where
|pointers are returned differently than integers (as in some 68000 compilers
|that return ints in D0 and pointers in A0 for the very good reason that it's
|more efficient that way when the result is going to be used immediately), or
|on any number of other environments that don't look like VAXes.

Suppose for one moment that at least the header file has been included
(or fix this in the same moment (John Mashey's b category)).  Then malloc
will have been declared as returning a void * or (non ANSI) char *, and
nothing is wrong with the declaration of BAR.  Not even on fancy addressing
machines.

Followups to comp.lang.c since this hasn't got anything to do with
computer architecture.

Tiggr