Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!haven!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: BUG - unsigned long cast to double Message-ID: <13315@mimsy.UUCP> Date: 31 Aug 88 05:38:57 GMT References: <1239500001@osiris.cso.uiuc.edu> <2590@ncr-sd.SanDiego.NCR.COM> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 41 >In article <1239500001@osiris.cso.uiuc.edu> olson@osiris.cso.uiuc.edu writes: [various compilers convert as if from signed long to double] In article <2590@ncr-sd.SanDiego.NCR.COM> matt@ncr-sd.SanDiego.NCR.COM (Matt Costello) writes: >The problem has existed in PCC since the beginning, Probably true (I have not been around long enough to really know; I believe PCC appeared in phototypesetter V6, which I have never used.) >as the PDP-11 did not readily support 32 bit integers. Not a good excuse. I imagine it was simply never tested. >Neither the VAX nor the M68881 support conversions to or from unsigned >values either. Conversion on a VAX is easy: cvtl[fd] src,dst bgeq 0f; add[fd]2 $0[fd]4294967296.0,r2; 0: On a 68000 it would be something longer, but also involve testing the sign before or during conversion. >The code sequences to handle the unsigned long to double conversion >(and vice versa) would have imposed an unacceptable performace penalty, >so it wasn't done. Better slow than wrong. I think it was just an oversight. One could make the claim that unsigned division and modulus on a VAX impose an unacceptable performance penalty (it takes far more than the four instructions above), yet they were done. >I don't have my K&R here, but I don't even believe >that unsigned longs were legal back then. I believe the One True C Compiler (dmr's '11 compiler) :-) did not have unsigned variants. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris