🚀 go-pugleaf

> 	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...).  
	The biggest problems I've found with DRI C is that it is VERY
sensitive to parameters matching.  I've found several programs
I've ported from MS-DOS that work happily there but give me mushrooms
on the ST.  So far, the problem has ALWAYS been mismatched parameters.
You have to pass ints to ints, chars to chars, and pointers to pointers.
(and longs to longs!).  Any mismatch, and bye bye.  Hope that helps.
  Bruce Wampler - ucbvax!unmvax!wampler

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.)

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.

In article <12189506892.49.UC.BRI@DEEP-THOUGHT.MIT.EDU> UC.BRI%DEEP-THOUGHT@EDDIE.MIT.EDU (Brian Totty) wrote:
>	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.

To which holloway@drivax.UUCP (Bruce Holloway) replied:
> 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.

But what if the window *isn't* on top? Is there then some way of scrolling?

Steven Pemberton, CWI, Amsterdam; steven@mcvax.uucp