(char *)malloc(100) (Re: 64 bits--why stop there?)

Tiggr rcpieter at svin02.info.win.tue.nl
Sat Sep 1 19:38:14 AEST 1990


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

>In article <1375 at svin02.info.win.tue.nl> rcpieter at 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



More information about the Comp.lang.c mailing list