UC.BRI%DEEP-THOUGHT@EDDIE.MIT.EDU (Brian Totty) (03/10/86)
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 -------
holloway@drivax.UUCP (Bruce Holloway) (03/11/86)
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.)
rb@ccivax.UUCP (03/12/86)
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.