Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!agate!ucbvax!POSTGRES.BERKELEY.EDU!dillon From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) Newsgroups: comp.sys.amiga Subject: Re: trouble opening intuition.library Message-ID: <8811272312.AA10996@postgres.Berkeley.EDU> Date: 27 Nov 88 23:12:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 41 mermelstein%tel.inrs.cdn@relay.ubc.ca (lois mermelstein) Writes: :IntuitionBase = (struct IntuitionBase *)OpenLibrary("intuition.library", : INTUITION_REV); :When the constant INUITION_REV is set to 33 or 0, I simply get "Couldn't open :lib." from the printf. When I set it to 33L or 0L, I get "software error -- :task held", with a guru number of "#0000000A.00C [plus some other numbers]. : :I'm using Manx 3.6A with the default c.lib (16 bit ints) on a 2-floppy :B2000 that's completely vanilla (nothing else running, nothing bizarre :in the startup-sequence). This is a standard mistake when using 16 bit integers. OpenLibrary() returns a pointer, what you have above is OpenLibrary() returning an integer and then casting it to a pointer ... which doesn't work well since pointers are 32 bits and integers are 16 bits. What you want to do is DECLARE OpenLibrary() as returning a pointer: extern char *OpenLibrary(); I.E, *ANY* kind of pointer. Doesn't make sense to declare it to return a struct IntuitionBase * since OpenLibrary() does other things, so you still need the cast as you have it but now, at least, it is converting a pointer to another pointer rather than an int to a pointer. :#define INTUITION_REV /*either 33, 0, 33L, or 0L */ Same problem .. I believe Aztec expects a long, so 33L or 0L. .. passing just an int (33, 0) would be incorrect. This is one of the many reasons I use +L (32 bit ints). Everybody says it makes for slower code and larger binaries. I have found that the code speed is more related to programmer experience rather than the size of ints, and although the binaries are larger for +L they aren't *that* much larger. Other people say that my reasons are silly because then I write incorrect code. I say they are silly because you can write incorrect code easily no matter what sized ints you use and my way saves me hours of worry... again, a matter relating to experience, NOT 16/32 bit ints. >Lois Mermelstein -Matt