Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!rochester!ritcv!ccivax!rb
From: rb@ccivax.UUCP
Newsgroups: net.micro.atari16
Subject: Re: Alcyon C: What bugs are there?
Message-ID: <464@ccivax.UUCP>
Date: Tue, 11-Mar-86 20:40:55 EST
Article-I.D.: ccivax.464
Posted: Tue Mar 11 20:40:55 1986
Date-Received: Sat, 15-Mar-86 04:07:48 EST
References: <12189506892.49.UC.BRI@DEEP-THOUGHT.MIT.EDU>
Reply-To: rb@ccivax.UUCP (What's in a name ?)
Organization: CCI Telephony Systems Group,  Rochester NY
Lines: 28
Keywords: Pointers/Ints
Summary: A general caution

In article <12189506892.49.UC.BRI@DEEP-THOUGHT.MIT.EDU> UC.BRI%DEEP-THOUGHT@EDDIE.MIT.EDU (Brian Totty) writes:
>
>	Could anyone tell me what bugs there are in the DRI C compiler?
>I am working on some GEM programs, and I keep getting bus errors (the
>ole' double mushrooms...).  I couldn't think of anything I did wrong,
>so I atarted wondering about a bug in the compiler (Yeah...if the program
>doesn't work blame it on the compiler...I know.).  In any case, the bus
>error comes in on a link instruction, which looks awfully close to a local
>variable init code.  Is there any chance that the DRI C compiler has a
>frame problem somewhere?  I would appreciate any info and possible fixes.

This may be obvious to you or not, but it is important and of general interest.

The DRI C compiler uses 16 bit ints, and 32 bit pointers (only 24 bits
significant).  Having worked with another such compiler (also 68K), there
are a few "gotchas" to worry about.  In particular, even though you may
have casted, cleaned, and linted (unix 'C' verifier) your code, it can
still go crazy.  I had a similar link problem when passing a pointer as
an int, going the other way can cause problems on the return.  Of course,
a pointer casted as integer loses significant bits, and casting the other
way can either be sign extended (used to force a crash), or trunkated,
which can do interesting things if the code is modified.

For some of the other "gotchas", look at some of the archives in net.lang.c

This is "acceptable" behavior, but other compilers using 32 bit ints
are more predictable (and slower).  The DRI version is faster, but code
needs to be very carefully checked.