Xref: utzoo comp.arch:17969 comp.lang.c:31521 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.arch,comp.lang.c Subject: (char *)malloc(100) (Re: 64 bits--why stop there?) Message-ID: Date: 31 Aug 90 16:45:31 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> <141658@sun.Eng.Sun.COM> <1375@svin02.info.win.tue.nl> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Followup-To: comp.lang.c Organization: Xenix Support, FICC Lines: 14 In article <1375@svin02.info.win.tue.nl> rcpieter@svin02.info.win.tue.nl (Tiggr) writes: > So it is not a problem of a bit-adressing machine but of a braindead compiler. No, it's neither. It's a case of incompatibilities between ints and pointers. There are *lots* of machines where leaving malloc undeclared will produce garbage: Intel anything. Small 68000 systems. Any 68000 system with efficient code generation (returning pointers in A0 instead of D0 is a pretty obvious win). Word-addressed machines. Always declare everything, or expect things to fail. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com