| Alcyon C: What bugs are there? [message #282966] |
Mon, 10 March 1986 01:41  |
|
|
Originally posted by: UC.BRI%DEEP-THOUGHT
<pre>
Article-I.D.: DEEP-THO.12189506892.49.UC.BRI
Posted: Mon Mar 10 01:41:12 1986
Date-Received: Tue, 11-Mar-86 01:22:50 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 25
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.
Also, how have people approached window text scrolling? V_gtext
is far too slow for a complete offset text redraw. I would like to do
a bit scroll, but the GEM manual was very hazy on how to do this, and I
am not sure if desk accessories on top of a window would screw up the
bits when scrolled. I actually would like a scroll rectangle call like
on the Macintosh, that gives redraw messages for the scrolled area under
the desk accessory. Any help here would also be great...
Thanks,
--- Bri
-------
</pre>
|
|
|
|
| Re: Alcyon C: What bugs are there? [message #283007 is a reply to message #282966] |
Tue, 11 March 1986 13:08  |
|
|
Originally posted by: holloway
<pre>
Article-I.D.: drivax.330
Posted: Tue Mar 11 13:08:29 1986
Date-Received: Fri, 14-Mar-86 04:10:28 EST
References: <12189506892.49.UC.BRI@DEEP-THOUGHT.MIT.EDU>
Reply-To: holloway@drivax.UUCP (Bruce Holloway)
Organization: Digital Research, Monterey, CA
Lines: 43
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.
There ARE bugs in the Alcyon compiler (the one in the Atari developer's kit),
but they mostly have to do with automatic type conversion to/from LONGs.
Occasionally it actually ignores a line for no apparent reason (I hate it
when that happens). It's very rare, though. Either you ran out of stack
space, or it's an error in your program. I've never gotten a bus error using
the Alcyon C compiler and traced it to the compiler.
> Also, how have people approached window text scrolling? V_gtext
> is far too slow for a complete offset text redraw. I would like to do
> a bit scroll, but the GEM manual was very hazy on how to do this, and I
> am not sure if desk accessories on top of a window would screw up the
> bits when scrolled. I actually would like a scroll rectangle call like
> on the Macintosh, that gives redraw messages for the scrolled area under
> the desk accessory. Any help here would also be great...
If you're running a desk accessory or filling out a form or a dialog box or
something similar, then no background processes are running. If you have
an active window (hence, on top), you can use the "Copy Raster, Opaque"
call (vro_cpyfm) to just BitBLT the window up one character height (said
height can be gotten from Inquire Current Face Information [vqt_fontinfo])
and another BitBLT to clear out the last row.
--
+----------------------------------------------------------- -----------------+
|Whatever I write are not the opinions or policies of Digital Research, Inc.,|
|and probably won't be in the foreseeable future. |
+----------------------------------------------------------- -----------------+
Bruce Holloway
....!ucbvax!hplabs!amdahl!drivax!holloway
(I'm not THAT Bruce Holloway, I'm the other one.)
</pre>
|
|
|
|
| Re: Alcyon C: What bugs are there? [message #283024 is a reply to message #282966] |
Tue, 11 March 1986 20:40 |
rb
Messages: 94
Registered: February 2013
Karma: 0
|
Member |
|
|
<pre>
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.
</pre>
|
|
|
|
Members
Search
Help
Register
Login
Home
