Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!think.com!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!svin02!rcpieter From: rcpieter@svin02.info.win.tue.nl (Tiggr) Newsgroups: comp.lang.c Subject: Re: (char *)malloc(100) (Re: 64 bits--why stop there?) Message-ID: <1377@svin02.info.win.tue.nl> Date: 1 Sep 90 09:38:14 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> 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. We had already established (if you follow this thread from the start) that malloc had been declared. And, the sentence you cut out of the complete posting was in fact referring to a very braindead compiler which held pointers as byte pointers on this bit addressing machine (it suddenly occurs to me that if pointers are held as byte pointers, and an undeclared malloc returns this thing, cast to an int, assuming the int looks exactly like a byte pointer in terms of size and appearance, then the (char *) cast of this malloc return value still is a legal byte pointer. But then again the int probably looked very different from a byte pointer so things went wrong after all). >Always declare everything, or expect things to fail. In short, given a bit addressing machine, a decent compiler and a programmer who knows how to declare things properly (preferably forced to do so by an ANSI C compiler) and who does not perform pointer arithmic via ints, this machine (and any other) should NOT cause any weirdeties (eh?). Followup to /dev/null. Tiggr