Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles; site uiucuxc.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!hamilton From: hamilton@uiucuxc.UUCP Newsgroups: net.bugs Subject: Re: bug in some 68000 C-compilers Message-ID: <10900007@uiucuxc.UUCP> Date: Thu, 13-Sep-84 03:00:00 EDT Article-I.D.: uiucuxc.10900007 Posted: Thu Sep 13 03:00:00 1984 Date-Received: Tue, 25-Sep-84 01:22:47 EDT References: <228@digi-g.UUCP> Lines: 13 Nf-ID: #R:digi-g:-22800:uiucuxc:10900007:000:636 Nf-From: uiucuxc!hamilton Sep 13 02:00:00 1984 i reported this problem a while back (in net.micro, i think); it's effects are even more widespread. my UniSoft C compiler reuses one half of the double result "register" as a scratchpad. you'll see similar problems with code like: double x[], atof(); x[i] = atof(...); the low-order fraction bits from the "atof" will get stomped by the index calculation. i "solved" my problem by avoiding "double"s altogether. i reported the problem to my micro vendor, who promised to pass the word on to unisoft. this was like last march... haven't heard another word about it since. wayne ({decvax,ucbvax}!pur-ee!uiucdcs!uiucuxc!)hamilton