sam@delftcc.UUCP (Sam Kendall) (06/25/85)
> > C casts are not bit-for-bit conversions unless the conversion happens > > to be implemented as such... > > . . . . > > I also don't understand what `happens to be implemented as' means. What > other possibilities are there for converting pointers to integers, > incompatible pointers, etc.? What is this, Stavros? Usually your condescension to C is supported by accuracy and clear thinking. Here are some examples of non-bit-for-bit conversions from C casts. On the UNIVAC, pointers are 48 bits, while even longs are only 32 bits; but in a 48-bit pointer there are 16 tag and semi-noise bits required by the hardware, so a pointer can be converted to an integer without loss of information. The resultant integer is an offset in bytes from the beginning of memory. Less obscurely, any machine that has more than one pointer format must use a non-bit-for-bit conversion in switching pointer formats. Such machines include the PDP-10 and many (all?) Data General machines. > I would put it differently: C casts ARE bit-for-bit conversions except > sometimes for numerical types. To the extent that one can speak of C > having any semantics at all, this makes the semantics of C casts grossly > inconsistent. For instance, (int) 2.3 == 2, but (*var=2.3, *((int *) > var) ) == garbage; I don't even want to begin to think about the > semantics of conversions involving unsigned's. As far as I can tell, you are saying here: "C casts ARE bit-for-bit conversions, because I say so. But numerical casts are NOT bit-for-bit. Therefore cast semantics are inconsistent." There may be a point lurking here, but I can't find it. As for the jibe about C's lack of semantics, there is a point here, too, but you haven't justified it. Sam Kendall UUCP: {allegra,cmcl2,ihnp4}!delftcc!sam Delft Consulting Corp. ARPA: delftcc!sam@NYU-CMCL2.ARPA Phone: (212) 243-8700 USMail: 432 Park Av S, New York, NY 10016